One way around this is to get support for ParallelReader (I believe ParallelWriter is still in JIRA, contributed by Chuck) into Solr. http://lucene.apache.org/java/docs/api/org/apache/lucene/index/ParallelReader.html
Then you'd keep your big fields in one index, and the frequently modified and shorter fields in another index. But I never understood how you'd keep doc IDs in sync between the two, which is something that ParallelReader requires. Otis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simpy -- http://www.simpy.com/ - Tag - Search - Share ----- Original Message ---- From: Yonik Seeley <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Tuesday, February 13, 2007 6:17:00 PM Subject: Re: Tagging On 2/13/07, Binkley, Peter <[EMAIL PROTECTED]> wrote: > I still wonder if there's a good way of storing the tags outside the > Lucene index and using them via facets whose bitsets are manipulated > directly rather than being populated from the index. In my project, > reindexing a documents whenever a user adds a tag is very very bad, > since we're indexing potentially hundreds of pages of full text in the > body field of the document. A solution that gets the tag into the system > immediately without forcing a reindexing of the document is essential. Interesting... what are you indexing that is that large, the book contents? You could build a custom request handler and store tag info outside the index. You could also store it inside the index in separate documents as Erik does with Collex. For a more general solution, I'm thinking a separate lucene index might be ideal. -Yonik
