Another possibility is to do it backwards, it depends on how expensive the SQL query is I suppose. The idea would be to go ahead and to your SQL query *first*, then construct a Lucene Filter to use with your query using TermDocs/TermEnum.
I'd guess (without knowing much about your problem space) that *if* you can spin through your SQL query and extract all of the unique doc IDs acceptably quickly that you won't notice constructing the filter time-wise. Also, search through the user list archive for embedding Lucene in a database. I confess that that entire discussion flew right over my head, so I don't know if it's applicable, but........ Erick On Wed, Feb 13, 2008 at 12:21 PM, <[EMAIL PROTECTED]> wrote: > Hi, > > I have the following scenario: > > RDBMS which contains the metadata for documents (ID, customer number, > doctype etc.). > Now I want to add fulltext search support. > > So I will index the documents content in lucene and add the documents ID > as > a stored field in lucene. > > Now somebody wants to search like this: customer number 1234 AND content > "foo bar". > > So I go to lucene, search for content:"foo bar" and get back a hitlist > containing the documents IDs. > > Now - how to merge these Ids with the resultset of the RDBM's search for > customer number 1234? > > 1) select ... from ... where customer=1234 and ID in (<lucenes ID list>). > > or > > 2) select ... from ... where customer=1234 and them join both resultsets > in > the application. > > or > > 3) no idea :) > > What is best practice here? > > Thank you. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
