You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Aman Deep Singh <am...@gmail.com> on 2017/05/05 05:55:55 UTC
Automatic conversion to Range Query
Hi,
I'm facing a issue when i'm querying the Solr
my query is "xiomi Mi 5 -white [64GB/ 3GB]"
while my search field definition is
<fieldType name="text_word_delimiter" class="solr.TextField"
autoGeneratePhraseQueries="false" positionIncrementGap="100">
<analyzer type="index">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.PatternReplaceFilterFactory"
pattern="[^\dA-Za-z ]" replacement=" "/>
<filter class="solr.WordDelimiterFilterFactory"
catenateNumbers="1" generateNumberParts="1" splitOnCaseChange="1"
generateWordParts="1" preserveOriginal="1" catenateAll="1"
catenateWords="1"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
<analyzer type="query">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.ManagedSynonymFilterFactory" managed="synonyms_gdn"/>
<filter class="solr.PatternReplaceFilterFactory"
pattern="[^\dA-Za-z _]" replacement=" "/>
<filter class="solr.WordDelimiterFilterFactory"
catenateNumbers="0" generateNumberParts="1" splitOnCaseChange="1"
generateWordParts="1" splitOnNumerics="1" preserveOriginal="0"
catenateAll="0" catenateWords="0"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
</fieldType>
My generated query is
+(((Synonym(nameSearch:xiaomi nameSearch:xiomi)) (nameSearch:mi)
(nameSearch:5) -(Synonym(nameSearch:putih
nameSearch:white))*(nameSearch:[64gb/ TO 3gb])*)~4)
Now due to automatic conversion of query to Range query i'm not able
to find the result
Solr Version-6.4.2
Parser- edismax
Thanks,
Aman Deep Singh
Re: Automatic conversion to Range Query
Posted by Aman Deep Singh <am...@gmail.com>.
Yes hoss,
it only convert to the range query when there is two token only,,BTW
thanks for raising the issue
On 11-May-2017 5:38 AM, "Chris Hostetter" <ho...@fucit.org> wrote:
> : I'm facing a issue when i'm querying the Solr
> : my query is "xiomi Mi 5 -white [64GB/ 3GB]"
> ...
> : +(((Synonym(nameSearch:xiaomi nameSearch:xiomi)) (nameSearch:mi)
> : (nameSearch:5) -(Synonym(nameSearch:putih
> : nameSearch:white))*(nameSearch:[64gb/ TO 3gb])*)~4)
> ...
> : Now due to automatic conversion of query to Range query i'm not able
> : to find the result
> ...
> : Solr Version-6.4.2
> : Parser- edismax
>
> That's really suprising to me -- but i can reproduce what you're
> describing ... not sure if the "implicit" assumption thta you wanted a
> range query is intentional or a bug -- but it's certainly weird so i've
> file a jira: https://issues.apache.org/jira/browse/LUCENE-7821
>
> FWIW: It's not actaully anything special about edismax that's causing that
> to be parsed as a range query -- it seems that the underlying grammer
> (used by both the lucene & edismax solr QParsers) treats the "TO" as
> optional in a range query, so the remaining 2 "terms" inside the square
> brackets are considered the low/high ... if you'd had more then 2 terms
> (ie: "foo [64gb/ 3gb bar]") it wouldn't have parsed as a range query --
> which means edismax would have fallen back to rerying to parse it with
> automatic escaping.
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
Re: Automatic conversion to Range Query
Posted by Chris Hostetter <ho...@fucit.org>.
: I'm facing a issue when i'm querying the Solr
: my query is "xiomi Mi 5 -white [64GB/ 3GB]"
...
: +(((Synonym(nameSearch:xiaomi nameSearch:xiomi)) (nameSearch:mi)
: (nameSearch:5) -(Synonym(nameSearch:putih
: nameSearch:white))*(nameSearch:[64gb/ TO 3gb])*)~4)
...
: Now due to automatic conversion of query to Range query i'm not able
: to find the result
...
: Solr Version-6.4.2
: Parser- edismax
That's really suprising to me -- but i can reproduce what you're
describing ... not sure if the "implicit" assumption thta you wanted a
range query is intentional or a bug -- but it's certainly weird so i've
file a jira: https://issues.apache.org/jira/browse/LUCENE-7821
FWIW: It's not actaully anything special about edismax that's causing that
to be parsed as a range query -- it seems that the underlying grammer
(used by both the lucene & edismax solr QParsers) treats the "TO" as
optional in a range query, so the remaining 2 "terms" inside the square
brackets are considered the low/high ... if you'd had more then 2 terms
(ie: "foo [64gb/ 3gb bar]") it wouldn't have parsed as a range query --
which means edismax would have fallen back to rerying to parse it with
automatic escaping.
-Hoss
http://www.lucidworks.com/
Re: Automatic conversion to Range Query
Posted by Rick Leir <rl...@leirtech.com>.
Of course, I should have noticed he typed 3G instead of 32G.
On 2017-05-07 10:46 AM, Aman Deep Singh wrote:
> Yes Rick,
> User is actually typing this type of queries ,this was a random user query
> pick from access logs
>
>
> On 07-May-2017 7:29 PM, "Rick Leir" <rl...@leirtech.com> wrote:
>
> Hi Aman,
> Is the user actually entering that query? It seems unlikely. Perhaps you
> have a form selector for various Apple products. Could you not have an
> enumerated type for the products, and simplify everything? I must be
> missing something here. Cheers -- Rick
>
> On May 6, 2017 8:38:14 AM EDT, Shawn Heisey <ap...@elyograg.org> wrote:
>> On 5/5/2017 12:42 PM, Aman Deep Singh wrote:
>>> Hi Erick, I don't want to do the range query , That is why I'm using
>>> the pattern replace filter to remove all the non alphanumeric to
>> space
>>> so that this type of situation don't arrive,Since end user can query
>>> anything, also in the query I haven't mention any range related
>>> keyword (TO). If my query is like [64GB/3GB] it works fine and
>> doesn't
>>> convert to range query.
>> I hope I'm headed in the right direction here.
>>
>> Square brackets are special characters to the query parser -- they are
>> typically used to specify a range query. It's a little odd that Solr
>> would add the "TO" for you like it seems to be doing, but not REALLY
>> surprising. This would be happening *before* the parts of the query
>> make it to your analysis chain where you have the pattern replace
>> filter.
>>
>> If you want to NOT have special characters perform their special
>> function, but actually become part of the query, you'll need to escape
>> them with a backslash. Escaping all the special characters in your
>> query yields this query:
>>
>> xiomi Mi 5 \-white \[64GB\/ 3GB\]
>>
>> It's difficult to decide whether the dash character before "white" was
>> intended as a "NOT" operator or to be part of the query. You might not
>> want to escape that one.
>>
>> Thanks,
>> Shawn
> --
> Sorry for being brief. Alternate email is rickleir at yahoo dot com
>
Re: Automatic conversion to Range Query
Posted by Aman Deep Singh <am...@gmail.com>.
Yes Rick,
User is actually typing this type of queries ,this was a random user query
pick from access logs
On 07-May-2017 7:29 PM, "Rick Leir" <rl...@leirtech.com> wrote:
Hi Aman,
Is the user actually entering that query? It seems unlikely. Perhaps you
have a form selector for various Apple products. Could you not have an
enumerated type for the products, and simplify everything? I must be
missing something here. Cheers -- Rick
On May 6, 2017 8:38:14 AM EDT, Shawn Heisey <ap...@elyograg.org> wrote:
>On 5/5/2017 12:42 PM, Aman Deep Singh wrote:
>> Hi Erick, I don't want to do the range query , That is why I'm using
>> the pattern replace filter to remove all the non alphanumeric to
>space
>> so that this type of situation don't arrive,Since end user can query
>> anything, also in the query I haven't mention any range related
>> keyword (TO). If my query is like [64GB/3GB] it works fine and
>doesn't
>> convert to range query.
>
>I hope I'm headed in the right direction here.
>
>Square brackets are special characters to the query parser -- they are
>typically used to specify a range query. It's a little odd that Solr
>would add the "TO" for you like it seems to be doing, but not REALLY
>surprising. This would be happening *before* the parts of the query
>make it to your analysis chain where you have the pattern replace
>filter.
>
>If you want to NOT have special characters perform their special
>function, but actually become part of the query, you'll need to escape
>them with a backslash. Escaping all the special characters in your
>query yields this query:
>
>xiomi Mi 5 \-white \[64GB\/ 3GB\]
>
>It's difficult to decide whether the dash character before "white" was
>intended as a "NOT" operator or to be part of the query. You might not
>want to escape that one.
>
>Thanks,
>Shawn
--
Sorry for being brief. Alternate email is rickleir at yahoo dot com
Re: Automatic conversion to Range Query
Posted by Rick Leir <rl...@leirtech.com>.
Hi Aman,
Is the user actually entering that query? It seems unlikely. Perhaps you have a form selector for various Apple products. Could you not have an enumerated type for the products, and simplify everything? I must be missing something here. Cheers -- Rick
On May 6, 2017 8:38:14 AM EDT, Shawn Heisey <ap...@elyograg.org> wrote:
>On 5/5/2017 12:42 PM, Aman Deep Singh wrote:
>> Hi Erick, I don't want to do the range query , That is why I'm using
>> the pattern replace filter to remove all the non alphanumeric to
>space
>> so that this type of situation don't arrive,Since end user can query
>> anything, also in the query I haven't mention any range related
>> keyword (TO). If my query is like [64GB/3GB] it works fine and
>doesn't
>> convert to range query.
>
>I hope I'm headed in the right direction here.
>
>Square brackets are special characters to the query parser -- they are
>typically used to specify a range query. It's a little odd that Solr
>would add the "TO" for you like it seems to be doing, but not REALLY
>surprising. This would be happening *before* the parts of the query
>make it to your analysis chain where you have the pattern replace
>filter.
>
>If you want to NOT have special characters perform their special
>function, but actually become part of the query, you'll need to escape
>them with a backslash. Escaping all the special characters in your
>query yields this query:
>
>xiomi Mi 5 \-white \[64GB\/ 3GB\]
>
>It's difficult to decide whether the dash character before "white" was
>intended as a "NOT" operator or to be part of the query. You might not
>want to escape that one.
>
>Thanks,
>Shawn
--
Sorry for being brief. Alternate email is rickleir at yahoo dot com
Re: Automatic conversion to Range Query
Posted by Erik Hatcher <er...@gmail.com>.
Fair enough indeed. And as you've experienced, that other functionality includes syntax that needs escaping. If you're using SolrJ then there's a utility method to escape characters.
Erik
> On May 6, 2017, at 20:53, Aman Deep Singh <am...@gmail.com> wrote:
>
> Hi Erik,
> We can't use dismax as we are using the other functionality of edismax
> parser
>
> On 07-May-2017 12:13 AM, "Erik Hatcher" <er...@gmail.com> wrote:
>
> What about dismax instead of edismax? It might do the righter thing here
> without escaping.
>
>>> On May 6, 2017, at 12:57, Shawn Heisey <ap...@elyograg.org> wrote:
>>>
>>> On 5/6/2017 7:09 AM, Aman Deep Singh wrote:
>>> After escaping the square bracket the query is working fine, Is their
>>> any way in the parser to avoid the automatic conversion if not proper
>>> query will be passed like in my case even though I haven't passed
>>> proper range query (with keyword TO).
>>
>> If you use characters special to the query parser but don't want them
>> acted on by the query parser, then they need to be escaped. That's just
>> how things work, and it's not going to change.
>>
>> Thanks,
>> Shawn
>>
Re: Automatic conversion to Range Query
Posted by Aman Deep Singh <am...@gmail.com>.
Hi Erik,
We can't use dismax as we are using the other functionality of edismax
parser
On 07-May-2017 12:13 AM, "Erik Hatcher" <er...@gmail.com> wrote:
What about dismax instead of edismax? It might do the righter thing here
without escaping.
> On May 6, 2017, at 12:57, Shawn Heisey <ap...@elyograg.org> wrote:
>
>> On 5/6/2017 7:09 AM, Aman Deep Singh wrote:
>> After escaping the square bracket the query is working fine, Is their
>> any way in the parser to avoid the automatic conversion if not proper
>> query will be passed like in my case even though I haven't passed
>> proper range query (with keyword TO).
>
> If you use characters special to the query parser but don't want them
> acted on by the query parser, then they need to be escaped. That's just
> how things work, and it's not going to change.
>
> Thanks,
> Shawn
>
Re: Automatic conversion to Range Query
Posted by Erik Hatcher <er...@gmail.com>.
What about dismax instead of edismax? It might do the righter thing here without escaping.
> On May 6, 2017, at 12:57, Shawn Heisey <ap...@elyograg.org> wrote:
>
>> On 5/6/2017 7:09 AM, Aman Deep Singh wrote:
>> After escaping the square bracket the query is working fine, Is their
>> any way in the parser to avoid the automatic conversion if not proper
>> query will be passed like in my case even though I haven't passed
>> proper range query (with keyword TO).
>
> If you use characters special to the query parser but don't want them
> acted on by the query parser, then they need to be escaped. That's just
> how things work, and it's not going to change.
>
> Thanks,
> Shawn
>
Re: Automatic conversion to Range Query
Posted by Shawn Heisey <ap...@elyograg.org>.
On 5/6/2017 7:09 AM, Aman Deep Singh wrote:
> After escaping the square bracket the query is working fine, Is their
> any way in the parser to avoid the automatic conversion if not proper
> query will be passed like in my case even though I haven't passed
> proper range query (with keyword TO).
If you use characters special to the query parser but don't want them
acted on by the query parser, then they need to be escaped. That's just
how things work, and it's not going to change.
Thanks,
Shawn
Re: Automatic conversion to Range Query
Posted by Aman Deep Singh <am...@gmail.com>.
Thanks Shawn,
After escaping the square bracket the query is working fine,
Is their any way in the parser to avoid the automatic conversion if not
proper query will be passed like in my case even though I haven't passed
proper range query (with keyword TO).
On 06-May-2017 6:08 PM, "Shawn Heisey" <ap...@elyograg.org> wrote:
On 5/5/2017 12:42 PM, Aman Deep Singh wrote:
> Hi Erick, I don't want to do the range query , That is why I'm using
> the pattern replace filter to remove all the non alphanumeric to space
> so that this type of situation don't arrive,Since end user can query
> anything, also in the query I haven't mention any range related
> keyword (TO). If my query is like [64GB/3GB] it works fine and doesn't
> convert to range query.
I hope I'm headed in the right direction here.
Square brackets are special characters to the query parser -- they are
typically used to specify a range query. It's a little odd that Solr
would add the "TO" for you like it seems to be doing, but not REALLY
surprising. This would be happening *before* the parts of the query
make it to your analysis chain where you have the pattern replace filter.
If you want to NOT have special characters perform their special
function, but actually become part of the query, you'll need to escape
them with a backslash. Escaping all the special characters in your
query yields this query:
xiomi Mi 5 \-white \[64GB\/ 3GB\]
It's difficult to decide whether the dash character before "white" was
intended as a "NOT" operator or to be part of the query. You might not
want to escape that one.
Thanks,
Shawn
Re: Automatic conversion to Range Query
Posted by Shawn Heisey <ap...@elyograg.org>.
On 5/5/2017 12:42 PM, Aman Deep Singh wrote:
> Hi Erick, I don't want to do the range query , That is why I'm using
> the pattern replace filter to remove all the non alphanumeric to space
> so that this type of situation don't arrive,Since end user can query
> anything, also in the query I haven't mention any range related
> keyword (TO). If my query is like [64GB/3GB] it works fine and doesn't
> convert to range query.
I hope I'm headed in the right direction here.
Square brackets are special characters to the query parser -- they are
typically used to specify a range query. It's a little odd that Solr
would add the "TO" for you like it seems to be doing, but not REALLY
surprising. This would be happening *before* the parts of the query
make it to your analysis chain where you have the pattern replace filter.
If you want to NOT have special characters perform their special
function, but actually become part of the query, you'll need to escape
them with a backslash. Escaping all the special characters in your
query yields this query:
xiomi Mi 5 \-white \[64GB\/ 3GB\]
It's difficult to decide whether the dash character before "white" was
intended as a "NOT" operator or to be part of the query. You might not
want to escape that one.
Thanks,
Shawn
Re: Automatic conversion to Range Query
Posted by Aman Deep Singh <am...@gmail.com>.
I'm using a custom request handler with deftype as edismax
My query is -
xiomi Mi 5 -white [64GB/ 3GB]
On 06-May-2017 12:48 AM, "Erick Erickson" <er...@gmail.com> wrote:
OK, what _request handler_ are you using? what is the original query?
On Fri, May 5, 2017 at 11:42 AM, Aman Deep Singh
<am...@gmail.com> wrote:
> Hi Erick,
> I don't want to do the range query ,
> That is why I'm using the pattern replace filter to remove all the non
> alphanumeric to space so that this type of situation don't arrive,Since
end
> user can query anything, also in the query I haven't mention any range
> related keyword (TO).
> If my query is like [64GB/3GB] it works fine and doesn't convert to range
> query.
>
> Thanks,
> Aman deep singh
>
> On 06-May-2017 12:04 AM, "Erick Erickson" <er...@gmail.com> wrote:
>
> I'm going to go a little sideways and claim this is an "XY" problem,
> the range bits are a side-issue. The problem is that you're trying to
> do ranges on textual data that are really numbers. So even if there's
> a way to fix the range issue you're talking about, it still won't do
> what you expect.
>
> Consider
> [3000000 TO 4] is perfectly valid for _character_ based data. At least
> it'll match values like 31, 32, 399999. That's not what a numeric sort
> would expect though. If you really want to search on numeric ranges,
> you'll have to split the value out to something that's really numeric.
>
> Best,
> Erick
>
> On Thu, May 4, 2017 at 10:55 PM, Aman Deep Singh
> <am...@gmail.com> wrote:
>> Hi,
>> I'm facing a issue when i'm querying the Solr
>> my query is "xiomi Mi 5 -white [64GB/ 3GB]"
>> while my search field definition is
>>
>> <fieldType name="text_word_delimiter" class="solr.TextField"
>> autoGeneratePhraseQueries="false" positionIncrementGap="100">
>> <analyzer type="index">
>> <tokenizer class="solr.WhitespaceTokenizerFactory"/>
>> <filter class="solr.PatternReplaceFilterFactory"
>> pattern="[^\dA-Za-z ]" replacement=" "/>
>> <filter class="solr.WordDelimiterFilterFactory"
>> catenateNumbers="1" generateNumberParts="1" splitOnCaseChange="1"
>> generateWordParts="1" preserveOriginal="1" catenateAll="1"
>> catenateWords="1"/>
>> <filter class="solr.LowerCaseFilterFactory"/>
>> </analyzer>
>> <analyzer type="query">
>> <tokenizer class="solr.StandardTokenizerFactory"/>
>> <filter class="solr.ManagedSynonymFilterFactory"
> managed="synonyms_gdn"/>
>> <filter class="solr.PatternReplaceFilterFactory"
>> pattern="[^\dA-Za-z _]" replacement=" "/>
>> <filter class="solr.WordDelimiterFilterFactory"
>> catenateNumbers="0" generateNumberParts="1" splitOnCaseChange="1"
>> generateWordParts="1" splitOnNumerics="1" preserveOriginal="0"
>> catenateAll="0" catenateWords="0"/>
>> <filter class="solr.LowerCaseFilterFactory"/>
>> </analyzer>
>> </fieldType>
>>
>>
>> My generated query is
>>
>>
>> +(((Synonym(nameSearch:xiaomi nameSearch:xiomi)) (nameSearch:mi)
>> (nameSearch:5) -(Synonym(nameSearch:putih
>> nameSearch:white))*(nameSearch:[64gb/ TO 3gb])*)~4)
>>
>>
>> Now due to automatic conversion of query to Range query i'm not able
>> to find the result
>>
>>
>> Solr Version-6.4.2
>>
>> Parser- edismax
>>
>> Thanks,
>>
>> Aman Deep Singh
Re: Automatic conversion to Range Query
Posted by Erick Erickson <er...@gmail.com>.
OK, what _request handler_ are you using? what is the original query?
On Fri, May 5, 2017 at 11:42 AM, Aman Deep Singh
<am...@gmail.com> wrote:
> Hi Erick,
> I don't want to do the range query ,
> That is why I'm using the pattern replace filter to remove all the non
> alphanumeric to space so that this type of situation don't arrive,Since end
> user can query anything, also in the query I haven't mention any range
> related keyword (TO).
> If my query is like [64GB/3GB] it works fine and doesn't convert to range
> query.
>
> Thanks,
> Aman deep singh
>
> On 06-May-2017 12:04 AM, "Erick Erickson" <er...@gmail.com> wrote:
>
> I'm going to go a little sideways and claim this is an "XY" problem,
> the range bits are a side-issue. The problem is that you're trying to
> do ranges on textual data that are really numbers. So even if there's
> a way to fix the range issue you're talking about, it still won't do
> what you expect.
>
> Consider
> [3000000 TO 4] is perfectly valid for _character_ based data. At least
> it'll match values like 31, 32, 399999. That's not what a numeric sort
> would expect though. If you really want to search on numeric ranges,
> you'll have to split the value out to something that's really numeric.
>
> Best,
> Erick
>
> On Thu, May 4, 2017 at 10:55 PM, Aman Deep Singh
> <am...@gmail.com> wrote:
>> Hi,
>> I'm facing a issue when i'm querying the Solr
>> my query is "xiomi Mi 5 -white [64GB/ 3GB]"
>> while my search field definition is
>>
>> <fieldType name="text_word_delimiter" class="solr.TextField"
>> autoGeneratePhraseQueries="false" positionIncrementGap="100">
>> <analyzer type="index">
>> <tokenizer class="solr.WhitespaceTokenizerFactory"/>
>> <filter class="solr.PatternReplaceFilterFactory"
>> pattern="[^\dA-Za-z ]" replacement=" "/>
>> <filter class="solr.WordDelimiterFilterFactory"
>> catenateNumbers="1" generateNumberParts="1" splitOnCaseChange="1"
>> generateWordParts="1" preserveOriginal="1" catenateAll="1"
>> catenateWords="1"/>
>> <filter class="solr.LowerCaseFilterFactory"/>
>> </analyzer>
>> <analyzer type="query">
>> <tokenizer class="solr.StandardTokenizerFactory"/>
>> <filter class="solr.ManagedSynonymFilterFactory"
> managed="synonyms_gdn"/>
>> <filter class="solr.PatternReplaceFilterFactory"
>> pattern="[^\dA-Za-z _]" replacement=" "/>
>> <filter class="solr.WordDelimiterFilterFactory"
>> catenateNumbers="0" generateNumberParts="1" splitOnCaseChange="1"
>> generateWordParts="1" splitOnNumerics="1" preserveOriginal="0"
>> catenateAll="0" catenateWords="0"/>
>> <filter class="solr.LowerCaseFilterFactory"/>
>> </analyzer>
>> </fieldType>
>>
>>
>> My generated query is
>>
>>
>> +(((Synonym(nameSearch:xiaomi nameSearch:xiomi)) (nameSearch:mi)
>> (nameSearch:5) -(Synonym(nameSearch:putih
>> nameSearch:white))*(nameSearch:[64gb/ TO 3gb])*)~4)
>>
>>
>> Now due to automatic conversion of query to Range query i'm not able
>> to find the result
>>
>>
>> Solr Version-6.4.2
>>
>> Parser- edismax
>>
>> Thanks,
>>
>> Aman Deep Singh
Re: Automatic conversion to Range Query
Posted by Aman Deep Singh <am...@gmail.com>.
Hi Erick,
I don't want to do the range query ,
That is why I'm using the pattern replace filter to remove all the non
alphanumeric to space so that this type of situation don't arrive,Since end
user can query anything, also in the query I haven't mention any range
related keyword (TO).
If my query is like [64GB/3GB] it works fine and doesn't convert to range
query.
Thanks,
Aman deep singh
On 06-May-2017 12:04 AM, "Erick Erickson" <er...@gmail.com> wrote:
I'm going to go a little sideways and claim this is an "XY" problem,
the range bits are a side-issue. The problem is that you're trying to
do ranges on textual data that are really numbers. So even if there's
a way to fix the range issue you're talking about, it still won't do
what you expect.
Consider
[3000000 TO 4] is perfectly valid for _character_ based data. At least
it'll match values like 31, 32, 399999. That's not what a numeric sort
would expect though. If you really want to search on numeric ranges,
you'll have to split the value out to something that's really numeric.
Best,
Erick
On Thu, May 4, 2017 at 10:55 PM, Aman Deep Singh
<am...@gmail.com> wrote:
> Hi,
> I'm facing a issue when i'm querying the Solr
> my query is "xiomi Mi 5 -white [64GB/ 3GB]"
> while my search field definition is
>
> <fieldType name="text_word_delimiter" class="solr.TextField"
> autoGeneratePhraseQueries="false" positionIncrementGap="100">
> <analyzer type="index">
> <tokenizer class="solr.WhitespaceTokenizerFactory"/>
> <filter class="solr.PatternReplaceFilterFactory"
> pattern="[^\dA-Za-z ]" replacement=" "/>
> <filter class="solr.WordDelimiterFilterFactory"
> catenateNumbers="1" generateNumberParts="1" splitOnCaseChange="1"
> generateWordParts="1" preserveOriginal="1" catenateAll="1"
> catenateWords="1"/>
> <filter class="solr.LowerCaseFilterFactory"/>
> </analyzer>
> <analyzer type="query">
> <tokenizer class="solr.StandardTokenizerFactory"/>
> <filter class="solr.ManagedSynonymFilterFactory"
managed="synonyms_gdn"/>
> <filter class="solr.PatternReplaceFilterFactory"
> pattern="[^\dA-Za-z _]" replacement=" "/>
> <filter class="solr.WordDelimiterFilterFactory"
> catenateNumbers="0" generateNumberParts="1" splitOnCaseChange="1"
> generateWordParts="1" splitOnNumerics="1" preserveOriginal="0"
> catenateAll="0" catenateWords="0"/>
> <filter class="solr.LowerCaseFilterFactory"/>
> </analyzer>
> </fieldType>
>
>
> My generated query is
>
>
> +(((Synonym(nameSearch:xiaomi nameSearch:xiomi)) (nameSearch:mi)
> (nameSearch:5) -(Synonym(nameSearch:putih
> nameSearch:white))*(nameSearch:[64gb/ TO 3gb])*)~4)
>
>
> Now due to automatic conversion of query to Range query i'm not able
> to find the result
>
>
> Solr Version-6.4.2
>
> Parser- edismax
>
> Thanks,
>
> Aman Deep Singh
Re: Automatic conversion to Range Query
Posted by Erick Erickson <er...@gmail.com>.
I'm going to go a little sideways and claim this is an "XY" problem,
the range bits are a side-issue. The problem is that you're trying to
do ranges on textual data that are really numbers. So even if there's
a way to fix the range issue you're talking about, it still won't do
what you expect.
Consider
[3000000 TO 4] is perfectly valid for _character_ based data. At least
it'll match values like 31, 32, 399999. That's not what a numeric sort
would expect though. If you really want to search on numeric ranges,
you'll have to split the value out to something that's really numeric.
Best,
Erick
On Thu, May 4, 2017 at 10:55 PM, Aman Deep Singh
<am...@gmail.com> wrote:
> Hi,
> I'm facing a issue when i'm querying the Solr
> my query is "xiomi Mi 5 -white [64GB/ 3GB]"
> while my search field definition is
>
> <fieldType name="text_word_delimiter" class="solr.TextField"
> autoGeneratePhraseQueries="false" positionIncrementGap="100">
> <analyzer type="index">
> <tokenizer class="solr.WhitespaceTokenizerFactory"/>
> <filter class="solr.PatternReplaceFilterFactory"
> pattern="[^\dA-Za-z ]" replacement=" "/>
> <filter class="solr.WordDelimiterFilterFactory"
> catenateNumbers="1" generateNumberParts="1" splitOnCaseChange="1"
> generateWordParts="1" preserveOriginal="1" catenateAll="1"
> catenateWords="1"/>
> <filter class="solr.LowerCaseFilterFactory"/>
> </analyzer>
> <analyzer type="query">
> <tokenizer class="solr.StandardTokenizerFactory"/>
> <filter class="solr.ManagedSynonymFilterFactory" managed="synonyms_gdn"/>
> <filter class="solr.PatternReplaceFilterFactory"
> pattern="[^\dA-Za-z _]" replacement=" "/>
> <filter class="solr.WordDelimiterFilterFactory"
> catenateNumbers="0" generateNumberParts="1" splitOnCaseChange="1"
> generateWordParts="1" splitOnNumerics="1" preserveOriginal="0"
> catenateAll="0" catenateWords="0"/>
> <filter class="solr.LowerCaseFilterFactory"/>
> </analyzer>
> </fieldType>
>
>
> My generated query is
>
>
> +(((Synonym(nameSearch:xiaomi nameSearch:xiomi)) (nameSearch:mi)
> (nameSearch:5) -(Synonym(nameSearch:putih
> nameSearch:white))*(nameSearch:[64gb/ TO 3gb])*)~4)
>
>
> Now due to automatic conversion of query to Range query i'm not able
> to find the result
>
>
> Solr Version-6.4.2
>
> Parser- edismax
>
> Thanks,
>
> Aman Deep Singh