Uwe Schindler <u...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
