> >> 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 compatibility. > 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 exit; 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). Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
