22 okt 2009 kl. 20.00 skrev Chris Hostetter:
: I'm thinking a decorator with deletions on top of the original
reader, merged
: with the clone reader using a MultiReader. But this would still
require a new
you don't really mean a clone do you? ... you should just need a very
small index containing the new versions of the docs, in a
MultiReader with
another reader that wraps the orriginal but overlays some deleted docs
metadata.
Sorry, bad terminology. What I ment with "clone reader" is the reader
of an index containing only the "by a user cloned and modified entries
from the original database".
: So far I haven't done anything but considering wether it's doable
or not.
it sounds feasible .. but the real question is how many users you'll
be
dealing with. if it's a really small number you might be better off
just
haveing one complete index per user, if it's really big then the
number of
indexes you're managing could get problematic.
Lots of users at the same time. It should at least scale to handle a
hundred of them at the same time. Cloning the original index and add
the modifications sounds too expensive, but I might be wrong. I'm as
worried about the effect it would have on query response time as the
resources it would consume.
I know to little about the Searcher. What resources am I wasting by
creating multiple Searchers on the same IndexReader? (Not really the
same instance of IndexReader, there would be the deleted-decorator and
the MultiReader too.) Can I expect some sort of latency (except for
when retrieving data from the "per user index with modifications"-
reader)? Or is this stuff associated with the IndexReader rather than
the Searcher?
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
