lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: move TrieRange* to core?
Date Thu, 19 Mar 2009 20:55:26 GMT
Uwe Schindler <uwe@thetaphi.de> wrote:

> My problem is: In my opinion, this is all to complicated and nasty
> and bad API design.
>
> One nice, but hackish approach would be to define
> FieldCache.StopFillCacheException extends RuntimeException and throw
> this inside the parse function, if a trie value with shift>0
> occurs. A try-catch block around the TermEnum code can then simply
> stop iterating. Normal cache would not need to use it, but the trie
> code could throw this exception to stop iterating terms, so it can
> be just a internal hack (e.g.  package-private, if trie moves to
> o.a.l.search).

I like that approach!

Though it won't also solve the original problem in LUCENE-1372
(allowing multi-term fields in FieldCache, giving you control over
which term should "win").

Maybe, in time for 2.9, we should fix FieldCache, to switch all
parsers over to abstract base classes (keeping the current way,
deprecated).  This way we could make a new approach that allows more
control over things like stopping early, which term to favor, etc.

Or.... maybe we should just go and finally do LUCENE-831,
taking these needs into account.  That seems like the best
way forward?

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message