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
-
Key: LUCENE-1768
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
NumericRangeQuery
[
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 query
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://issues.apache.org/jira
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 parser
TermRangeQueryNode
- change 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 parser
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
Affects Versions: 2.9
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 parser
-
Key
factories without
instanceof checks.
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
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 support for new query parser
-
Key
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 support for new query parser
and RangeQueryNode objects.
Let me know if there is any question about what I just described.
NumericRange support for new query parser
-
Key: LUCENE-1768
URL: https://issues.apache.org/jira/browse/LUCENE-1768
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 support for new query
going to handle
back-compat here?
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
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 support for new query parser
postProcessNode to do its own
conversion?
NumericRange support for new query parser
-
Key: LUCENE-1768
URL: https://issues.apache.org/jira/browse/LUCENE-1768
Project: Lucene - Java
Issue Type: New
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 completely different implementations.
NumericRange support for new query
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.apache.org/jira/browse/LUCENE-1768
Project: Lucene - Java
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
Project: Lucene - Java
Issue Type: New
(a);
}
{code}
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
}
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
Affects
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 ranges in addition to
term ranges.
NumericRange support for new query parser
, it 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
Project: Lucene - Java
[
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 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
URL: https
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
-
Key: LUCENE-1768
URL: https
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 new query parser
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
-
Key: LUCENE-1768
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/browse/LUCENE-1768
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
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
31 matches
Mail list logo
