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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> > 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: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > -- >> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> > http://www.solrenterprisesearchserver.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
