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]
