[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

will need to convert the 2 ParametricQueryNode to the respective type, based on the user config: TermRangeQueryNode (renamed from RangeQueryNode) or NumericRangeQueryNode. > NumericRange support for new query parser > - > >

[jira] Updated: (LUCENE-1768) NumericRange support for new query parser

[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1768: -- Fix Version/s: (was: 2.9) 3.1 > NumericRange support for new qu

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

for field names (date, numeric, term) to create the correct range query. bq. +1 on pushing this. getRangeQuery() will still be first class. As noted in my comment on java-dev: We should add a comment in Javadocs, that the old (and also new) query parser do not work automatically with NumericRangeQ

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

not being deprecated, should this issue be pushed out to 3.0 or 3.1 to give it more time? In the meantime, people can use the existing override getRangeQuery() method. 2.9 is looking really close. {quote} +1 > NumericRange support for new query

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

It does seem like we should at least do this though: we should rename RangeQueryNode to TermRangeQueryNode (to match lucene name) > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: https:

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

eing deprecated, should this issue be pushed out to 3.0 or 3.1 to give it more time? In the meantime, people can use the existing override getRangeQuery() method. 2.9 is looking really close. > NumericRange support for new query

[jira] Issue Comment Edited: (LUCENE-1768) NumericRange support for new query parser

support for new query parser > - > > Key: LUCENE-1768 > URL: https://issues.apache.org/jira/browse/LUCENE-1768 > Project: Lucene - Java > Issue Type: New Feature > Componen

[jira] Issue Comment Edited: (LUCENE-1768) NumericRange support for new query parser

the ParametricRangeQueryNodeProcessor to read the configuration passed by the user and create the correct QueryNode objects. - create a new NumericQueryNodeBuilder add it to the StandardQueryTreeBuilder mapping. I hope this helps > NumericRange support for new query

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

the configuration passed by the user and create the correct QueryNode objects. - create a new NumericQueryNodeBuilder add it to the StandardQueryTreeBuilder mapping. I hope this helps > NumericRange support for new query parser > - > >

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

hen doing such things is, that you use instanceof checks before you try to cast some abstract return type to something specific, not documented. {quote} Agreed, I also think it's fine as long as it's documented > NumericRange suppor

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

eak, since the user's custom builder for RangeQueryNode would still be invoked, and the core's builder for NumericRangeQuery would handle the newly added numeric range support. I think this is reasonable. > NumericRange s

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

ted the objects returned from factories without instanceof checks. > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: https://issues.apache.org/jira/browse/LUCENE-1768 > Pr

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

uilderMap); {code} This way, if the user reset the RangeQueryNode builder to its own builder, it will still be called for XRangeQueryNode and RangeQueryNode objects. Let me know if there is any question about what I just described. > NumericRange support for new query parser > --

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

deprecate the standard QueryParser yet - and the new one should carry no back compat policy. It needs to be flushed out in a release before we tell users to move to it IMO. Not enough Committers have enough experience with it to promise back compat at this point I think. > NumericRange sup

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

s that users had added, for the RangeQuery node, will no loner be invoked. How are we going to handle back-compat here? > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: https://issues.

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

matically the correct range query for it." Because the old query parser is now "deprecated", I want to do it for the new one. This would also be an intention for new users to throw away the old parser and use the new one, because it can be configured easily to create numeric ra

[jira] Issue Comment Edited: (LUCENE-1768) NumericRange support for new query parser

topAnalyzer = new StandardAnalyzer(); qp.setAnalyzer(oneStopAnalyzer); Query a = qp.parse("date:[" + startDate + " TO " + endDate + "]", null); System.out.print(a); } {code} > NumericRange support for new query parser > --

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

Query a = qp.parse("date:[" + startDate + " TO " + endDate + "]", null); System.out.print(a); } {code} > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: ht

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

will work, but the builder will be performing the tasks the Processor should be doing. > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: https://issues.apache.org/jira/browse/LUCENE-1768 >

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

t be, but there are so many classes in the new QP, I'm having a little difficulty finding my way around. > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: https://issues.apach

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

to setFieldsBoost setDateResolution, already available on the old QP and the new flexible query parser. I also want to say, that extending the old QP vs extending the "New flexible Query Parser" approaches are never going to be similar, they

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

quot; package, that overrides postProcessNode to do its own conversion? > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: https://issues.apache.org/jira/browse/LUCENE-1768 > Pr

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

add much code and complexity. If the user already knows how to create a range query in code, it's much more straightforward to just do {code} if ("money".equals(field)) return new NumericRangeQuery(field,...) else return super.getRangeQuery(field,...) {code} > NumericRange suppor

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

pes qp.setRangeTypes(rangeTypes); Query q = qp.parser(" month:[01/01/2004 TO 01/01/2005] distance:[1000 to 2000] money: [23.50 to 50.99]"); {code} > NumericRange support for new query parser > - > >

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

The standard way in the past was for the app to simply override getRangeQuery() to handle different fields differently. This still seems the most flexible. > NumericRange support for new query parser > - > > Key: LUCENE-1768 >

[jira] Assigned: (LUCENE-1768) NumericRange support for new query parser

[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-1768: -- Assignee: Uwe Schindler > NumericRange support for new query par

[jira] Updated: (LUCENE-1768) NumericRange support for new query parser

should be not so hard. I will prepare something tomorrow. > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: https://issues.apache.org/jira/browse/LUCENE-1768 > Proj

[jira] Issue Comment Edited: (LUCENE-1768) NumericRange support for new query parser

so applies to this query. Example code for creating the NRQ are in the JavaDocs and there are 2 JUnits in trunk (TestNumericRangeQuery*) showing how it is used. Also the new LIA2 contains a chapter about it. > NumericRange support for new query parser > ---

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

a subclass of MultiTermQuery so the rewrite method also applies to this query. Example code for creating the NRQ are in the JavaDocs and there are 2 JUnits in trunk (TestNumericRangeQuery*) showing how it is used. Also the new LIA2 contains a chapter about it. > NumericRange support for

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

that retrives just one of those docs and not the other without using the queryparser, that would be helpful. > NumericRange support for new query parser > - > > Key: LUCENE-1768 > URL: https://issues.apache.org

[jira] Created: (LUCENE-1768) NumericRange support for new query parser

NumericRange support for new query parser - Key: LUCENE-1768 URL: https://issues.apache.org/jira/browse/LUCENE-1768 Project: Lucene - Java Issue Type: New Feature Components: QueryParser

Re: new query

you'll probably get more responses to a question about how to use lucene if you use the java-user list (the java-dev list is for discussing deevelopment of the core lucene library) : How to search numbers using Lucene API : I an using a demo application so as to search the documents but when i :

new query

How to search numbers using Lucene API I an using a demo application so as to search the documents but when i search the numbers or alphanumeric text it appends an empty space and no hits are returned any help would be appreciated ---

DO NOT REPLY [Bug 34453] New: - Query parts ending with a colon are handled badly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu