If there is an API to adjust the inverted index directly, it would be much
efficient.
I guess Mirko's problem is similar to this: There could be a "main_record"
table and "category" table. Each "main_record" has a "category".
When one "category" is changed, quite some "main_record" are affected.
The usual first choice when using Lucene to search database data is to
denormalize the db data into the index. Yes, it's redundant, but it's often
a better solution than trying to use both. Synchronization can be an issue,
but you have to deal with that anyway since you're indexing from the db
anyw
The data from db is required for sorting, and one db entry matches to many
index entries, so storing it in the index would be redundant. Also there would
be the challenge to keep index and db in sync. Any ideas?
Mirko
-Ursprüngliche Nachricht-
Von: Ian Lea [mailto:ian@gmail.com]
Ge
If the sorting and pagination doesn't require data from the database,
just do db lookups for the hits on a page, page by page as required.
But if the db data is required I'd suggest storing it in the index.
--
Ian.
On Wed, Sep 1, 2010 at 1:43 PM, Sertic Mirko, Bedag
wrote:
> Hi
>
>
>
> I need t
Hi
I need to implement sorting and pagination of lucene search results.
This is quite easy, but I have to combine Data from the index with data
from a database. The index has the fulltext data plus a unique
identifier for a record from the database. The database stores
additional data. Fulltext
