[jira] [Updated] (SOLR-10266) invalid assumptions about doc order in TestPointFields - possibly masking real bug in {{DatePointField}} ?

["Hoss Man (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated SOLR-10266:
----------------------------
    Attachment: SOLR-10266.patch


Here's the patch of what i've got so far, generally making 2 changes everywhere the test has an implicit assumption about the order docs would be returned:

* change the order the test _adds_ the docs in to be (effectively) be "id desc"
** this forces solr's implicit default sort to mismatch the existing implicitly expected order (even if no funky merging happens) so the tests would fail reliably regardless of seed
* add a sort by "id asc" everywhere the {{assertQ()}} calls had an implicit assumption that the results would be returned in "id" order

(in a few places early on in my fixes, I also added some tighter asserts to the range query testing as well)

there is one nocommit in this patch, in {{doTestDatePointFunctionQuery}}...

AFAICT something is really wrong with the first {{assertQ}} in this test -- which is specifically about sorting by a function on the date point field (which also uses DocValues).

Even w/o any of my changes, I can't see any reason why the doc order currently listed in this assert should be the expected doc order for the specified sort.  It looks backwards to me.  And when I flip the order the documents are added to the index, the actual order returned flips as well -- suggesting that the sort by function is having no effect at all.

This suggests that sorting by function on {{DatePointField}} may not be working? ... either that or maybe the particular function used in this test isn't valid for date fields and results in identical values for all docs? (i've never tried usig {{product(...)}} on a date before)

----

[~caomanhdat] - i know you just added {{DatePointField}} support in SOLR-9986, can you please take a look at the nocommit in this patch?

> invalid assumptions about doc order in TestPointFields - possibly masking real bug in {{DatePointField}} ?
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-10266
>                 URL: https://issues.apache.org/jira/browse/SOLR-10266
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>         Attachments: SOLR-10266.patch
>
>
> There are a bunch of places in TestPointFields where {{assertQ()}} is used to verify that many docs match a query and have particular values -- but because of how the XPath expressions are written there are implicit assumptions about the order of the docs matching the order they were added to the index, which isn't always garunteed depending on the randomized merge policy that might be used.
> while fixing this, i also uncovered what _appears_ to be a more serious bug with {{DatePointField}} function sorting (either that, or a badly written test) that we need to get to the bottom of.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org