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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
