If the old index is optimized then you might be able to iterate
through
all the docs in your old index (sorted by doc id) and for each
iteration
add the corresponding doc to the new index so it has a matching doc
id.
The idea being that after searching on one index you could use the doc
id to look up the corresponding doc in the other index.
True - it would be like using Lucene as a thin relational DB.
However, I don't want to just be able to associate the new fields
with the old, I also want to be able to search over them.
Right now, I'm thinking of rolling a custom MultiSearcher that
operates over two indices containing identical fileIDs, and returns
the set intersection of fileIDs returned from their respective
searches; i.e. a search for "contents:germany title:medicine" would
get the fileIDs containing "germany" in the contents index, the
fileIDs containing "medicine" in the new index, find the fileIDs in
both sets of hits, and return them.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
