lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Move TrieRange to Core/Module and integration issues
Date Mon, 13 Apr 2009 21:01:04 GMT
> > 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message