0

I'm just curious why Lucene doesn't distinguish string and numeric values in a standard way.. for example ['2' TO '6'] and [2 TO 6] for range queries and treat all of them by default as String.

Is there any particular reason to treat both of these cases as the string values?

alexanoid
  • 24,051
  • 54
  • 210
  • 410

1 Answers1

1

Your range query example is based on lucene query syntax. In this definition it's not defined in what kind of field type you execute this query.

Basically if you apply this query to a TextField the evaluation will be based on String. If you apply this to a IntPoint the number will be interpreted as integer. Responsible for this is the QueryParser in which you add your query and your field you like to search.

In your case using an IntPoint would make sense because you want to search for an numeric range.

More details about the query parser see QueryParser Javadoc

dom
  • 732
  • 7
  • 19
  • I understand this. I don't understand why do not use for example `TermRangeQuery.NumericRangeFilter` in case of non-quoted values(like `[2 TO 6]`) in the range queries and textual range queries in case of quoted values like `['2' TO '6']`? – alexanoid Jun 01 '18 at 08:29
  • whats the idea? you like to see immediately if it's a string or numberic range if you see the query syntax? – dom Jun 01 '18 at 08:35
  • yes, I'd like to see the Lucene Query parser to be smart enough to be able to distinguish string literals(based on the quotes) and others. This is a huge blocker to me right now in order to port my Neo4j applications to use Lucene index instead of non-indexed properties on relationships. – alexanoid Jun 01 '18 at 08:39
  • afaik this is not possible with lucene query syntax (didn't had may use cases like this to be honest). so you tried with string literals and it's not going to work? – dom Jun 01 '18 at 08:43
  • yeah :( unfortunately, I ran into the following issue https://stackoverflow.com/questions/50545551/neo4j-manual-explicit-indexes-and-non-string-range-queries and don't see any solutions how it can be solved – alexanoid Jun 01 '18 at 08:45
  • i don't know neo4j indexing. as i understand you have a problem with range queries in neo4j right? and you have existing queries which are no longer proper executable? – dom Jun 01 '18 at 10:55
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/172236/discussion-between-dom-and-alexanoid). – dom Jun 01 '18 at 11:02
  • no, everything is working fine with the existing Neo4j queries based on pure Neo4j relationship properties. But in order to improve the performance, I'm trying to use another Neo4j option - manual indexes which are based on the Lucene engine. There I use pure Lucene query language and this is where I ran into the issue of this subject when I tried to rewrite my old queries to the Lucene query language. So, honestly, I can't see any specific issue to Neo4j here... this issue relates only to Lucene. – alexanoid Jun 01 '18 at 12:00
  • well based on lucene query language it's not an issue. it just works like how described in the answer. so you have to find a workarround. what do you try to achieve? migrate those queries automatically? or does it bother you that string literals are not used? :) – dom Jun 01 '18 at 13:52
  • it is impossible to migrate these queries automatically. I have rewritten my query builder to support Lucene Query language and when the 99% of work was done - I ran into this issue. A few hundred tests were passed except the tests that use numeric range queries. – alexanoid Jun 01 '18 at 13:54
  • ok so your basic problem is that you can't do range queries? because this is possible based on this answer: https://stackoverflow.com/questions/50540788/lucene-query-language-and-numeric-range – dom Jun 01 '18 at 13:56
  • Not in the way I have asked in my question – alexanoid Jun 01 '18 at 13:57