> -----Original Message----- > From: Michael McCandless [mailto:luc...@mikemccandless.com] > Sent: Monday, March 09, 2009 12:51 PM > To: java-user@lucene.apache.org > Subject: Re: Lucene 2.9 > > > Uwe Schindler wrote: > > >>> Is there any plans to have simpler queries for Numbers and Data? > >> > >> With the recent addition of TrieRangeQuery (in 2.9), I think Lucene's > >> range querying is actually very strong, though you'd have to subclass > >> QueryParser and override getRangeQuery to have it create > >> TrieRangeQuery. > > > > The additions for QueryParser to support this are done in Solr > > (because in > > contrast to Lucene alone, Solr knows the datatype and encoding) of > > each > > field: https://issues.apache.org/jira/browse/SOLR-940 > > > > You can do it in the same way. Maybe we should supply some "plugin" > > for the > > QueryParser in TrieRange contrib? > > +1 > > Or perhaps we should move Trie* into core Lucene, and then build a > real (ootb) integration with QueryParser.
The problem is that the query parser does not know if a field is encoded as trie or is just a normal text token. Furthermore, the new trie API does not differentiate between dates, doubles, longs (same for 32bit) because every trie field is identical (it is the application's task to keep track on the encoding when indexing and searching, TrieRange only supports the conversion of these data types to sortable integers), but the "datatype" itself is not stored in index. Solr has support for this in its "schema", but for Lucene all fields are identical. For the query parser there is no possibility to differentiate between a long, double or date. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
