lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cohan, Sean" <SCo...@goSPS.com>
Subject RE: Indexing in a CBD Environment
Date Tue, 10 Dec 2002 23:40:07 GMT
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>


Mime
View raw message