lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject RE: Indexing in a CBD Environment
Date Wed, 11 Dec 2002 06:16:39 GMT
Hm.  Is Lucene really the best tool for this job?
Anyhow, I'm not going to get into details, but this makes me think of
Zoe.  Zoe is a nice app that handles email in 'novel' ways, and is
built on top of Lucene, among other things.  It uses Lucene as an
object store, of sort, I believe, with variuos relations between
objects (I did not look at the source, but I suspect it does this based
on the functionality it offers).  You may want to look at its source.
Bed.

Otis


--- "Cohan, Sean" <SCohan@goSPS.com> wrote:
> I was thinking that may help, but not sure if it will completely
> solve our
> problems.  I'll try to give an overly simplified example.
> 
> Say we have a user table in a user component with columns of varying
> types
> (int, char, varchar, date.)  Say we have a note table in note
> component with
> date and varchar note columns.  A user can create notes so we want to
> associate notes in the note component to users in the user component,
> (there
> could be other apps or parts of our app creating other kinds of notes
> [i.e.,
> not user notes.])  To map the 2, say we have an associative table in
> the
> user component containing user foreign keys and note foreign keys.
> 
> I think we want several types of indexes, but I may be wrong given my
> limited knowledge on search engine design.  I think we may want to an
> index
> of the user columns and an index of note columns.  Easy enough.  The
> tricky
> one is an index of user info with their associated note info.  We
> want to be
> able to search for note info tied to a specific user or specific
> lists of
> users.  If that note info changes (say by some means other than the
> user to
> which it is associated) how do we re-fresh the index tying the user
> to the
> new note info?  How do we keep things in sync in the index if the
> data is
> spread out among several databases.
> 
> Perhaps there is a better index design than what I stated above.  
> 
> In actuality, we will have a core component containing objects
> related to
> several other components so we will several associative tables.  We
> would
> want to be able to tie the core component objects to each of the
> other
> related components within the index(es.)  To further compound things,
> the
> sub component objects could be related to their own sub-components
> (D, E,
> and F below.)
> 
> Hopefully, I've kind of clarified what it is we're trying to do, and
> hopefully, someone can aid us in coming up with a good approach using
> Lucene.
> 
> Thanks. 
> 
> 
> -----Original Message-----
> From: Doug Cutting [mailto:cutting@lucene.com]
> Sent: Tuesday, December 10, 2002 5:51 PM
> To: Lucene Users List
> Subject: Re: Indexing in a CBD Environment
> 
> 
> I'm not sure I understand the question, but I'll hazard an answer 
> anyway.  Might it work to maintain separate indexes for B, C, E and
> F, 
> then use a MultiSearcher to search them all?  That would keep updates
> 
> local...
> 
> Doug
> 
> Cohan, Sean wrote:
> > I am a total newbie to Lucene.  We are developing using a
> Component-Based
> > Development (CBD) approach (j2ee, oracle, linux) where our app is
> built
> > using separate stand-alone components.  The standalone components
> may
> reside
> > on separate boxes and will typically have their own databases.  
> > 
> > From what I understand, Lucene operates on a collection of flat
> documents
> > (or objects) of a single type at one time.  For our project, we
> need a
> > search that will operate on a diverse range of objects that are
> interrelated
> > by foreign keys.  
> > 
> > We have thought of constructing a flat multi-field document that
> represents
> > the tree of all dependent objects we wish to search. 
> Unfortunately, doing
> > so is difficult to do with CBD.  
> > 
> > Object Hierarchy                  Flattened Document
> > 
> >     A                             A.A-field1
> >     |                             A.A-field2
> > +---+---+                         A.B-field1
> > |   |   |                         A.B-field2
> > B   C   D                         A.C-field1
> >         +--+                      A.D-field1
> >         |  |                      A.D-E-field1
> >         E  F                      A.D-F-field1
> > 
> > In the example above, if you want to index the object tree
> indicated by
> the
> > diagram at left, you can do so easily upon an update of A, by
> traversing
> the
> > tree, to produce something that looks like the flattened document
> at
> right.
> > The problem comes when you want to individually update objects B-F.
> > Assuming these objects are in other components (i.e., databases)
> that have
> > no knowledge of A, there is no way to update their data within the
> context
> > of the hierarchy.
> > 
> > We can't think of any way to make the flat structure of Lucerne
> work with
> > CBD.
> > 
> > We greatly appreciate any ideas or suggestions.  Thanks.
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:
> <mailto:lucene-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:lucene-user-help@jakarta.apache.org>
> > 
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:lucene-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-user-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:  
> <mailto:lucene-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-user-help@jakarta.apache.org>
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <mailto:lucene-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-user-help@jakarta.apache.org>


Mime
View raw message