> > 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)?
I will prepare a patch that makes the members protected instead of private with appropinquate javadocs and then I can go on with a first implementation of the TermEnum. I will do this all in the contrib area with the current package name. Moving/renaming can be done later (but hopefully before 2.9). > 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". I wanted to direct attention to that again :-) > > 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. Yes. Just for comparison: This is exactly done like so in Solr (with the schema in xml format fort he index). Maybe this can be a reference, how such a schema could look like. The important things in the Schema for a Field are things like type, how to get a ValueSource (both for function queries and for sorting), how to convert the type to java objects (toObject() in solr returns e.g. java.lang.Integer and so on). But solrs schema has too many thing is comparison to Lucene like analyzers and so on. This should be stripped down, to the important things. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
