Hi, It is really nice idea to have something like if I am doing a query like amount >15 something depending upon the field and do query parsing. Basically we need have pluggable query parser which can convert different queries like amount >15 to lucene specified query.
That is what I think. I am using Lucene for long time and love to see this kind of stuff. Though Minin provided this I am not really happy with performance nor the GPL and probably it is love toward using things from Apache Foundation (Tomcat, Lucene, Common, HTTPD etc) . Regards, Allahbaksh Mohammedali Asadullah, http://allahbaksh.blogspot.com Starting a startup is hard, but having a 9 to 5 job is hard too, and in some ways a worse kind of hard. -----Original Message----- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Monday, March 09, 2009 6:41 PM To: java-user@lucene.apache.org Subject: Re: Lucene 2.9 Uwe Schindler wrote: >> 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. Could we add APIs to QueryParser so the application can state the disposition toward certain fields? EG QueryParser now tries to guess whether a range query's upper/lower bound should be parsed as dates, and there are methods exposed to set the resolution on a per-field basis. Maybe we could do something similar to declare that a given field uses Trie*, and with what datatype. Just thinking aloud really... but since we haven't yet released Trie*, now (for 2.9) is a good time to think hard about how we expose/integrate it... and making it easier to use ootb seems important. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
