lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: move TrieRange* to core?
Date Thu, 19 Mar 2009 18:40:30 GMT
> >> If so... maybe we could extend FieldCache's parser to allow it to
> >> stop-early?  Ie it'd get the TermEnum, iterate through all the full
> >> precision terms first, asking your parser to convert to long/int,
> >> and then when your parser sees the very first not-full-precision
> >> term, it tells FieldCache to stop.
> >>
> >> Would that work?
> >
> > Yes, good idea! In this case it is really better, that the higher
> > precision terms come first. The question is how to implement that /
> > extend the current API.
> Maybe, to also allow extensibility for LUCENE-1372, we should let a
> parser optionally just do the whole loop?
> Ie, you're given an IndexReader & String field, and you return an
> int[].
> We could eg make an AdvancedIntParser abstract class, implementing
> IntParser, and then getInts would check if the parser you passed in is
> an instance of AdvancedIntParser, and would just call its getInts
> method if so.

This is all a little bit complicated, because the current parsers are
interfaces and are not extensible at the moment. If they were abstract
classes, we could add a getInts() method (and others), that contain the code
from the current Cache inner class, that fills the cache using
TermEnum/TermDocs. Simple implementations could just overwrite parseInt(),
the trie parser would also overwrite getInts() and delegates the parsing to
parseInt() (only if shift==0). But this is not possible with backwards

> It's a bit ugly, because AdvancedIntParser would have to implement a
> no-op parseInt.  But it should be back compatible.

It need not to be no-op. The AdvancedParser's getInts() could call it for
valid terms. So if (term.charAt(0)==SHIFT_START_INT) parseInt(term) else

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message