Also raised SOLR-10709 for the q=field:* case. On Thu, May 18, 2017 at 8:29 AM, Erick Erickson <[email protected]> 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 <[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]
