On Mon, Apr 13, 2009 at 12:05 PM, Uwe Schindler <u...@thetaphi.de> wrote:
> For me it would not be a problem, I would use a FilteredTermEnum and > subclass it, but would only implement next() and the other abstract methods > would be dummies (including difference() returning 1.0f). Only the enum and > the term should have a protected access or a getter in this class. Seems like this is simplest (relax FilteredTermEnum so that it could be extended, and then you can subclass it with dummies)? This sounds like a great step forward overall; it's nice to have all queries that are based on multiple terms share MultiTermQuery. Moving things to the proper sub-packages, and renaming, also makes alot of sense. Re core or module or contrib, it's still being discussed under uber-thread "Modularization". > Something other: How about storing the "type" information in FieldInfos and > invent a AbstractField subclass for numbers (NumberField) returning the > TrieTokenStream in tokenSteam()? This could help people to index. When > searching, query parsers could use the information and construct the right > queries, sorting would automatically choose the right ValueSource/Parser and > so on. I would love to do something along these lines (LUCENE-1597 is also exploring better typed fields/documents). Once FieldInfos can properly store the fact that a given field has NumericType (which'd have options to turn on sorting, range filtering, etc.), then we could default many things properly without requiring the app to do "per field" things in N different places. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
