On Sunday 12 June 2011 22:12:01 Michael McCandless wrote: > Anyway, I don't think that's a good tradeoff, in general, for our > users, because very few apps truly require immediate consistency from > Lucene (can anyone give an example where their app depends on > immediate consistency...?
For database (enterprise resource planning) applications we are in progress of replacing native database queries to lucene queries, because lucene offers an efficient combination of fulltext and structured (including facets) queries. Til now clients expect that if they change something it will be immediately reflected in their "lists" aka queries. If lucene reopen() won't be sufficient in performance (I didn't measure) we would solve it by an additional short lived index for new objects, which complicates the architecture, or by modifying the merge strategy. > I think it's better to spend time during reopen so that searches > aren't slower. Absolutely, if you build an internet search engine. For our closed world with numbered clients search speed doesn't have that impact. It must scale for one client on one cpu core - and buy as many cores as necessary. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
