You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Erick Erickson <er...@gmail.com> on 2017/05/17 18:57:57 UTC
DocValues and searching, not finding known values. Solr 6x
Not sure
1> whether these behaviors are unexpected
2> whether it's in Lucene or Solr
Trying to get my arms around searching times on tlong fields where
docValues=true, indexed=false. I see two behaviors:
************behavior 1
multiValued=true or false doesn't matter.
This query:
q=eoemulti:6850281131226296000
fails to return this doc:
{
id: "ac43badb-baea-409a-8d7c-15fb9022eb57",
eoesingle: -9223216310394490000,
eoemulti:
[
-8165935356757264000,
-246919588995914140,
6850281131226296000
],
_version_: 1567669858451062800
},
Doing the same thing on a single valued field also fails, i.e. this query
q=eoesingle:9223350502980951000
does not return this doc:
{
id: "c7e1cbc6-e5dc-46fa-965f-3550b3df0b4f",
eoesingle: 9223350502980951000,
eoemulti:
[
-8898576911607905000,
3423452543074020000,
4253741925414605000
],
_version_: 1567669860794630100
},
This fails to return the above too:
q=eoesingle:[9223350502980951000 TO 9223350502980951000]
If I make the range "big enough", it succeeds, i.e. This returns the above doc:
q=eoesingle:[8223350502980900000 TO 9223350502980951100]
Interestingly, things succeed when the value I add in my indexing
program is random.nextInt(1_000_000) but fail when I use
random.nextLong(). The values aren't a sparse set in the nextInt case
though whereas they are in the nextLong() case, perhaps an off-by-one
error?
ALSO: I couldn't get this to fail on a quick junit hack, not quite
sure what's up with that.
Worth a JIRA or do I not understand how searching on a non-indexed MV
DV field should work? Also if it is a worth a JIRA I'm not sure
whether a Lucene or Solr, haven't traced it that far.
************behavior 2
multiValued=false in this case.
q=eoe:*
unexpected docvalues type NUMERIC for field 'eoe' (expected one of
[SORTED, SORTED_SET]). Re-index with correct docvalues type.
Note if multiValued=true this works whether there are more than one
value in the MV field or just a single value.
Raise one or two JIRAS here?
Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: DocValues and searching, not finding known values. Solr 6x
Posted by Erick Erickson <er...@gmail.com>.
Also raised SOLR-10709 for the q=field:* case.
On Thu, May 18, 2017 at 8:29 AM, Erick Erickson <er...@gmail.com> wrote:
> Adrien:
>
> Thanks for looking. So to try to answer your question I indexed only a
> single document with that value, one field with index=true,
> docValues=false and one with indexed=false, docValues=true. The parsed
> query is fine in both cases. Also, both cases are found in the
> single-document case.
>
> It's apparently only in the case where there are lots of values in
> there where the problem happens. Anyway, it looks like these are worth
> JIRAs so let's move the discussion over there. See SOLR-10708
>
> Erick
>
>
> On Wed, May 17, 2017 at 11:27 PM, Adrien Grand <jp...@gmail.com> wrote:
>> Behaviour 1 looks like your long values get casted to double then to back to
>> long at index or search time. That would explain both why the exact query
>> doesn't work since `6850281131226296000` is not accurately representable as
>> a double (it gets rounded to 6850281131226296320) and why the range starts
>> matching as soon as you make it wider. If you can inspect the content of
>> your index to check what values are actually stored, it could help figure
>> out whether the problem is at index or search time.
>>
>> Le jeu. 18 mai 2017 à 05:56, Erick Erickson <er...@gmail.com> a
>> écrit :
>>>
>>> I did both from a clean slate several times on my local box, deleting
>>> the entire data dir each time.
>>>
>>> I may have some time tomorrow to see if I can get a test to fail. My
>>> current working theory is that my test was too elementary since it
>>> only indexed a couple of documents and if the "off by one" error is
>>> the culprit then I can see why the degenerate cases wouldn't hit it.
>>>
>>> I didn't try to write a test for behavior 2, but it happens every time
>>> on my system, again wiping the data dir each time. That one should be
>>> fairly easy to write a test for as it doesn't look like it needs much
>>> special.
>>>
>>> Erick
>>>
>>>
>>>
>>> On Wed, May 17, 2017 at 7:22 PM, David Smiley <da...@gmail.com>
>>> wrote:
>>> > Behavior 1: I don't think this is expected at all. You could raise a
>>> > JIRA... but I wonder what's going on in the particular environment where
>>> > you're seeing this that may be related. So trying to reproduce it in a
>>> > JUnit test is next (I think). Or try manually from a clean slate. You
>>> > said
>>> > you tried but haven't been able to reproduce it... you could try harder
>>> > or
>>> > again look at what's different in the customer/client env.
>>> >
>>> > Behavior 2: Not expected, I think. Again, try and reproduce with a test
>>> > (or
>>> > at least trying manual from a clean slate) and if successful, file a
>>> > JIRA.
>>> >
>>> > On Wed, May 17, 2017 at 2:58 PM Erick Erickson <er...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Not sure
>>> >> 1> whether these behaviors are unexpected
>>> >> 2> whether it's in Lucene or Solr
>>> >>
>>> >> Trying to get my arms around searching times on tlong fields where
>>> >> docValues=true, indexed=false. I see two behaviors:
>>> >>
>>> >> ************behavior 1
>>> >>
>>> >> multiValued=true or false doesn't matter.
>>> >>
>>> >> This query:
>>> >>
>>> >> q=eoemulti:6850281131226296000
>>> >>
>>> >> fails to return this doc:
>>> >> {
>>> >> id: "ac43badb-baea-409a-8d7c-15fb9022eb57",
>>> >> eoesingle: -9223216310394490000,
>>> >> eoemulti:
>>> >> [
>>> >> -8165935356757264000,
>>> >> -246919588995914140,
>>> >> 6850281131226296000
>>> >> ],
>>> >> _version_: 1567669858451062800
>>> >> },
>>> >>
>>> >> Doing the same thing on a single valued field also fails, i.e. this
>>> >> query
>>> >> q=eoesingle:9223350502980951000
>>> >>
>>> >> does not return this doc:
>>> >> {
>>> >> id: "c7e1cbc6-e5dc-46fa-965f-3550b3df0b4f",
>>> >> eoesingle: 9223350502980951000,
>>> >> eoemulti:
>>> >> [
>>> >> -8898576911607905000,
>>> >> 3423452543074020000,
>>> >> 4253741925414605000
>>> >> ],
>>> >> _version_: 1567669860794630100
>>> >> },
>>> >>
>>> >>
>>> >> This fails to return the above too:
>>> >> q=eoesingle:[9223350502980951000 TO 9223350502980951000]
>>> >>
>>> >> If I make the range "big enough", it succeeds, i.e. This returns the
>>> >> above
>>> >> doc:
>>> >> q=eoesingle:[8223350502980900000 TO 9223350502980951100]
>>> >>
>>> >> Interestingly, things succeed when the value I add in my indexing
>>> >> program is random.nextInt(1_000_000) but fail when I use
>>> >> random.nextLong(). The values aren't a sparse set in the nextInt case
>>> >> though whereas they are in the nextLong() case, perhaps an off-by-one
>>> >> error?
>>> >>
>>> >> ALSO: I couldn't get this to fail on a quick junit hack, not quite
>>> >> sure what's up with that.
>>> >>
>>> >> Worth a JIRA or do I not understand how searching on a non-indexed MV
>>> >> DV field should work? Also if it is a worth a JIRA I'm not sure
>>> >> whether a Lucene or Solr, haven't traced it that far.
>>> >>
>>> >> ************behavior 2
>>> >> multiValued=false in this case.
>>> >> q=eoe:*
>>> >>
>>> >> unexpected docvalues type NUMERIC for field 'eoe' (expected one of
>>> >> [SORTED, SORTED_SET]). Re-index with correct docvalues type.
>>> >>
>>> >> Note if multiValued=true this works whether there are more than one
>>> >> value in the MV field or just a single value.
>>> >>
>>> >> Raise one or two JIRAS here?
>>> >>
>>> >> Erick
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>> > --
>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> > http://www.solrenterprisesearchserver.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: DocValues and searching, not finding known values. Solr 6x
Posted by Erick Erickson <er...@gmail.com>.
Adrien:
Thanks for looking. So to try to answer your question I indexed only a
single document with that value, one field with index=true,
docValues=false and one with indexed=false, docValues=true. The parsed
query is fine in both cases. Also, both cases are found in the
single-document case.
It's apparently only in the case where there are lots of values in
there where the problem happens. Anyway, it looks like these are worth
JIRAs so let's move the discussion over there. See SOLR-10708
Erick
On Wed, May 17, 2017 at 11:27 PM, Adrien Grand <jp...@gmail.com> wrote:
> Behaviour 1 looks like your long values get casted to double then to back to
> long at index or search time. That would explain both why the exact query
> doesn't work since `6850281131226296000` is not accurately representable as
> a double (it gets rounded to 6850281131226296320) and why the range starts
> matching as soon as you make it wider. If you can inspect the content of
> your index to check what values are actually stored, it could help figure
> out whether the problem is at index or search time.
>
> Le jeu. 18 mai 2017 à 05:56, Erick Erickson <er...@gmail.com> a
> écrit :
>>
>> I did both from a clean slate several times on my local box, deleting
>> the entire data dir each time.
>>
>> I may have some time tomorrow to see if I can get a test to fail. My
>> current working theory is that my test was too elementary since it
>> only indexed a couple of documents and if the "off by one" error is
>> the culprit then I can see why the degenerate cases wouldn't hit it.
>>
>> I didn't try to write a test for behavior 2, but it happens every time
>> on my system, again wiping the data dir each time. That one should be
>> fairly easy to write a test for as it doesn't look like it needs much
>> special.
>>
>> Erick
>>
>>
>>
>> On Wed, May 17, 2017 at 7:22 PM, David Smiley <da...@gmail.com>
>> wrote:
>> > Behavior 1: I don't think this is expected at all. You could raise a
>> > JIRA... but I wonder what's going on in the particular environment where
>> > you're seeing this that may be related. So trying to reproduce it in a
>> > JUnit test is next (I think). Or try manually from a clean slate. You
>> > said
>> > you tried but haven't been able to reproduce it... you could try harder
>> > or
>> > again look at what's different in the customer/client env.
>> >
>> > Behavior 2: Not expected, I think. Again, try and reproduce with a test
>> > (or
>> > at least trying manual from a clean slate) and if successful, file a
>> > JIRA.
>> >
>> > On Wed, May 17, 2017 at 2:58 PM Erick Erickson <er...@gmail.com>
>> > wrote:
>> >>
>> >> Not sure
>> >> 1> whether these behaviors are unexpected
>> >> 2> whether it's in Lucene or Solr
>> >>
>> >> Trying to get my arms around searching times on tlong fields where
>> >> docValues=true, indexed=false. I see two behaviors:
>> >>
>> >> ************behavior 1
>> >>
>> >> multiValued=true or false doesn't matter.
>> >>
>> >> This query:
>> >>
>> >> q=eoemulti:6850281131226296000
>> >>
>> >> fails to return this doc:
>> >> {
>> >> id: "ac43badb-baea-409a-8d7c-15fb9022eb57",
>> >> eoesingle: -9223216310394490000,
>> >> eoemulti:
>> >> [
>> >> -8165935356757264000,
>> >> -246919588995914140,
>> >> 6850281131226296000
>> >> ],
>> >> _version_: 1567669858451062800
>> >> },
>> >>
>> >> Doing the same thing on a single valued field also fails, i.e. this
>> >> query
>> >> q=eoesingle:9223350502980951000
>> >>
>> >> does not return this doc:
>> >> {
>> >> id: "c7e1cbc6-e5dc-46fa-965f-3550b3df0b4f",
>> >> eoesingle: 9223350502980951000,
>> >> eoemulti:
>> >> [
>> >> -8898576911607905000,
>> >> 3423452543074020000,
>> >> 4253741925414605000
>> >> ],
>> >> _version_: 1567669860794630100
>> >> },
>> >>
>> >>
>> >> This fails to return the above too:
>> >> q=eoesingle:[9223350502980951000 TO 9223350502980951000]
>> >>
>> >> If I make the range "big enough", it succeeds, i.e. This returns the
>> >> above
>> >> doc:
>> >> q=eoesingle:[8223350502980900000 TO 9223350502980951100]
>> >>
>> >> Interestingly, things succeed when the value I add in my indexing
>> >> program is random.nextInt(1_000_000) but fail when I use
>> >> random.nextLong(). The values aren't a sparse set in the nextInt case
>> >> though whereas they are in the nextLong() case, perhaps an off-by-one
>> >> error?
>> >>
>> >> ALSO: I couldn't get this to fail on a quick junit hack, not quite
>> >> sure what's up with that.
>> >>
>> >> Worth a JIRA or do I not understand how searching on a non-indexed MV
>> >> DV field should work? Also if it is a worth a JIRA I'm not sure
>> >> whether a Lucene or Solr, haven't traced it that far.
>> >>
>> >> ************behavior 2
>> >> multiValued=false in this case.
>> >> q=eoe:*
>> >>
>> >> unexpected docvalues type NUMERIC for field 'eoe' (expected one of
>> >> [SORTED, SORTED_SET]). Re-index with correct docvalues type.
>> >>
>> >> Note if multiValued=true this works whether there are more than one
>> >> value in the MV field or just a single value.
>> >>
>> >> Raise one or two JIRAS here?
>> >>
>> >> Erick
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> > --
>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> > http://www.solrenterprisesearchserver.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: DocValues and searching, not finding known values. Solr 6x
Posted by Adrien Grand <jp...@gmail.com>.
Behaviour 1 looks like your long values get casted to double then to back
to long at index or search time. That would explain both why the exact
query doesn't work since `6850281131226296000` is not accurately
representable as a double (it gets rounded to 6850281131226296320) and why
the range starts matching as soon as you make it wider. If you can inspect
the content of your index to check what values are actually stored, it
could help figure out whether the problem is at index or search time.
Le jeu. 18 mai 2017 à 05:56, Erick Erickson <er...@gmail.com> a
écrit :
> I did both from a clean slate several times on my local box, deleting
> the entire data dir each time.
>
> I may have some time tomorrow to see if I can get a test to fail. My
> current working theory is that my test was too elementary since it
> only indexed a couple of documents and if the "off by one" error is
> the culprit then I can see why the degenerate cases wouldn't hit it.
>
> I didn't try to write a test for behavior 2, but it happens every time
> on my system, again wiping the data dir each time. That one should be
> fairly easy to write a test for as it doesn't look like it needs much
> special.
>
> Erick
>
>
>
> On Wed, May 17, 2017 at 7:22 PM, David Smiley <da...@gmail.com>
> wrote:
> > Behavior 1: I don't think this is expected at all. You could raise a
> > JIRA... but I wonder what's going on in the particular environment where
> > you're seeing this that may be related. So trying to reproduce it in a
> > JUnit test is next (I think). Or try manually from a clean slate. You
> said
> > you tried but haven't been able to reproduce it... you could try harder
> or
> > again look at what's different in the customer/client env.
> >
> > Behavior 2: Not expected, I think. Again, try and reproduce with a test
> (or
> > at least trying manual from a clean slate) and if successful, file a
> JIRA.
> >
> > On Wed, May 17, 2017 at 2:58 PM Erick Erickson <er...@gmail.com>
> > wrote:
> >>
> >> Not sure
> >> 1> whether these behaviors are unexpected
> >> 2> whether it's in Lucene or Solr
> >>
> >> Trying to get my arms around searching times on tlong fields where
> >> docValues=true, indexed=false. I see two behaviors:
> >>
> >> ************behavior 1
> >>
> >> multiValued=true or false doesn't matter.
> >>
> >> This query:
> >>
> >> q=eoemulti:6850281131226296000
> >>
> >> fails to return this doc:
> >> {
> >> id: "ac43badb-baea-409a-8d7c-15fb9022eb57",
> >> eoesingle: -9223216310394490000,
> >> eoemulti:
> >> [
> >> -8165935356757264000,
> >> -246919588995914140,
> >> 6850281131226296000
> >> ],
> >> _version_: 1567669858451062800
> >> },
> >>
> >> Doing the same thing on a single valued field also fails, i.e. this
> query
> >> q=eoesingle:9223350502980951000
> >>
> >> does not return this doc:
> >> {
> >> id: "c7e1cbc6-e5dc-46fa-965f-3550b3df0b4f",
> >> eoesingle: 9223350502980951000,
> >> eoemulti:
> >> [
> >> -8898576911607905000,
> >> 3423452543074020000,
> >> 4253741925414605000
> >> ],
> >> _version_: 1567669860794630100
> >> },
> >>
> >>
> >> This fails to return the above too:
> >> q=eoesingle:[9223350502980951000 TO 9223350502980951000]
> >>
> >> If I make the range "big enough", it succeeds, i.e. This returns the
> above
> >> doc:
> >> q=eoesingle:[8223350502980900000 TO 9223350502980951100]
> >>
> >> Interestingly, things succeed when the value I add in my indexing
> >> program is random.nextInt(1_000_000) but fail when I use
> >> random.nextLong(). The values aren't a sparse set in the nextInt case
> >> though whereas they are in the nextLong() case, perhaps an off-by-one
> >> error?
> >>
> >> ALSO: I couldn't get this to fail on a quick junit hack, not quite
> >> sure what's up with that.
> >>
> >> Worth a JIRA or do I not understand how searching on a non-indexed MV
> >> DV field should work? Also if it is a worth a JIRA I'm not sure
> >> whether a Lucene or Solr, haven't traced it that far.
> >>
> >> ************behavior 2
> >> multiValued=false in this case.
> >> q=eoe:*
> >>
> >> unexpected docvalues type NUMERIC for field 'eoe' (expected one of
> >> [SORTED, SORTED_SET]). Re-index with correct docvalues type.
> >>
> >> Note if multiValued=true this works whether there are more than one
> >> value in the MV field or just a single value.
> >>
> >> Raise one or two JIRAS here?
> >>
> >> Erick
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> > --
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: DocValues and searching, not finding known values. Solr 6x
Posted by Erick Erickson <er...@gmail.com>.
I did both from a clean slate several times on my local box, deleting
the entire data dir each time.
I may have some time tomorrow to see if I can get a test to fail. My
current working theory is that my test was too elementary since it
only indexed a couple of documents and if the "off by one" error is
the culprit then I can see why the degenerate cases wouldn't hit it.
I didn't try to write a test for behavior 2, but it happens every time
on my system, again wiping the data dir each time. That one should be
fairly easy to write a test for as it doesn't look like it needs much
special.
Erick
On Wed, May 17, 2017 at 7:22 PM, David Smiley <da...@gmail.com> wrote:
> Behavior 1: I don't think this is expected at all. You could raise a
> JIRA... but I wonder what's going on in the particular environment where
> you're seeing this that may be related. So trying to reproduce it in a
> JUnit test is next (I think). Or try manually from a clean slate. You said
> you tried but haven't been able to reproduce it... you could try harder or
> again look at what's different in the customer/client env.
>
> Behavior 2: Not expected, I think. Again, try and reproduce with a test (or
> at least trying manual from a clean slate) and if successful, file a JIRA.
>
> On Wed, May 17, 2017 at 2:58 PM Erick Erickson <er...@gmail.com>
> wrote:
>>
>> Not sure
>> 1> whether these behaviors are unexpected
>> 2> whether it's in Lucene or Solr
>>
>> Trying to get my arms around searching times on tlong fields where
>> docValues=true, indexed=false. I see two behaviors:
>>
>> ************behavior 1
>>
>> multiValued=true or false doesn't matter.
>>
>> This query:
>>
>> q=eoemulti:6850281131226296000
>>
>> fails to return this doc:
>> {
>> id: "ac43badb-baea-409a-8d7c-15fb9022eb57",
>> eoesingle: -9223216310394490000,
>> eoemulti:
>> [
>> -8165935356757264000,
>> -246919588995914140,
>> 6850281131226296000
>> ],
>> _version_: 1567669858451062800
>> },
>>
>> Doing the same thing on a single valued field also fails, i.e. this query
>> q=eoesingle:9223350502980951000
>>
>> does not return this doc:
>> {
>> id: "c7e1cbc6-e5dc-46fa-965f-3550b3df0b4f",
>> eoesingle: 9223350502980951000,
>> eoemulti:
>> [
>> -8898576911607905000,
>> 3423452543074020000,
>> 4253741925414605000
>> ],
>> _version_: 1567669860794630100
>> },
>>
>>
>> This fails to return the above too:
>> q=eoesingle:[9223350502980951000 TO 9223350502980951000]
>>
>> If I make the range "big enough", it succeeds, i.e. This returns the above
>> doc:
>> q=eoesingle:[8223350502980900000 TO 9223350502980951100]
>>
>> Interestingly, things succeed when the value I add in my indexing
>> program is random.nextInt(1_000_000) but fail when I use
>> random.nextLong(). The values aren't a sparse set in the nextInt case
>> though whereas they are in the nextLong() case, perhaps an off-by-one
>> error?
>>
>> ALSO: I couldn't get this to fail on a quick junit hack, not quite
>> sure what's up with that.
>>
>> Worth a JIRA or do I not understand how searching on a non-indexed MV
>> DV field should work? Also if it is a worth a JIRA I'm not sure
>> whether a Lucene or Solr, haven't traced it that far.
>>
>> ************behavior 2
>> multiValued=false in this case.
>> q=eoe:*
>>
>> unexpected docvalues type NUMERIC for field 'eoe' (expected one of
>> [SORTED, SORTED_SET]). Re-index with correct docvalues type.
>>
>> Note if multiValued=true this works whether there are more than one
>> value in the MV field or just a single value.
>>
>> Raise one or two JIRAS here?
>>
>> Erick
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: DocValues and searching, not finding known values. Solr 6x
Posted by David Smiley <da...@gmail.com>.
Behavior 1: I don't think this is expected at all. You could raise a
JIRA... but I wonder what's going on in the particular environment where
you're seeing this that may be related. So trying to reproduce it in a
JUnit test is next (I think). Or try manually from a clean slate. You said
you tried but haven't been able to reproduce it... you could try harder or
again look at what's different in the customer/client env.
Behavior 2: Not expected, I think. Again, try and reproduce with a test
(or at least trying manual from a clean slate) and if successful, file a
JIRA.
On Wed, May 17, 2017 at 2:58 PM Erick Erickson <er...@gmail.com>
wrote:
> Not sure
> 1> whether these behaviors are unexpected
> 2> whether it's in Lucene or Solr
>
> Trying to get my arms around searching times on tlong fields where
> docValues=true, indexed=false. I see two behaviors:
>
> ************behavior 1
>
> multiValued=true or false doesn't matter.
>
> This query:
>
> q=eoemulti:6850281131226296000
>
> fails to return this doc:
> {
> id: "ac43badb-baea-409a-8d7c-15fb9022eb57",
> eoesingle: -9223216310394490000,
> eoemulti:
> [
> -8165935356757264000,
> -246919588995914140,
> 6850281131226296000
> ],
> _version_: 1567669858451062800
> },
>
> Doing the same thing on a single valued field also fails, i.e. this query
> q=eoesingle:9223350502980951000
>
> does not return this doc:
> {
> id: "c7e1cbc6-e5dc-46fa-965f-3550b3df0b4f",
> eoesingle: 9223350502980951000,
> eoemulti:
> [
> -8898576911607905000,
> 3423452543074020000,
> 4253741925414605000
> ],
> _version_: 1567669860794630100
> },
>
>
> This fails to return the above too:
> q=eoesingle:[9223350502980951000 TO 9223350502980951000]
>
> If I make the range "big enough", it succeeds, i.e. This returns the above
> doc:
> q=eoesingle:[8223350502980900000 TO 9223350502980951100]
>
> Interestingly, things succeed when the value I add in my indexing
> program is random.nextInt(1_000_000) but fail when I use
> random.nextLong(). The values aren't a sparse set in the nextInt case
> though whereas they are in the nextLong() case, perhaps an off-by-one
> error?
>
> ALSO: I couldn't get this to fail on a quick junit hack, not quite
> sure what's up with that.
>
> Worth a JIRA or do I not understand how searching on a non-indexed MV
> DV field should work? Also if it is a worth a JIRA I'm not sure
> whether a Lucene or Solr, haven't traced it that far.
>
> ************behavior 2
> multiValued=false in this case.
> q=eoe:*
>
> unexpected docvalues type NUMERIC for field 'eoe' (expected one of
> [SORTED, SORTED_SET]). Re-index with correct docvalues type.
>
> Note if multiValued=true this works whether there are more than one
> value in the MV field or just a single value.
>
> Raise one or two JIRAS here?
>
> Erick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com