[
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: [email protected]
For additional commands, e-mail: [email protected]
