[
https://issues.apache.org/jira/browse/SOLR-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-10807:
----------------------------
Attachment: core.test.log.txt
I've started experimenting with bulk change to all test schemas to use the
randomization logic -- or more specifically: a slight modification of the
existing randomization logic, because of the issues noted in SOLR-10177.
In a nutshell...
* change every schema, and every test that uses managed schema to create a
numeric field, to use a "randomly" choosen sysprop for defining the
Int/Float/Long/Double/Date FieldType Class name to use
** force the "random" logic to always choose points (temporarily)
*** NOTE: this still allows TrieFields for the tests that use
@SuppressPointFields
* HACK: in "test mode": force PointFields to ignore extra TrieField args (ie:
precisionStep)
** to minimize number of changes needed to test schemas
(w/o that last HACK, a simple "search and replace" in test schemas wouldn't be
good enough, because many schemas might have multiple "Integer" Trie fieldTypes
with diff precisionSteps -- I was looking for a simple brute force way to
replace every usage of Trie fields with Point fields ... even if it's not
something we want to commit to master)
Once that was in place, I started running tests and needed to HACK a few more
things to get past some large barrieres that were obvious very quickly...
* had to disable some useless code in ExternalFileField to get most schemas to
load
** should probably commit this change either way
* in SimpleFacets & StatsComponent, I tweaked the error handling to allow
uninversion of single valued points
** see SOLR-10472 which came after these error checks were added
** tests using multivalued non-DV numerics still fail of course, but a lot of
single valued ones seem to wrok now
* we have 48(!) test schemas that use numeric fields for the uniqueKey Field
(why?!?!?!)
** this very obviously/visibly breaks things like QEC on init - and lots of
configs have QEC registered even if the test doesn't care about it
** more subtly: it also breaks simple things like deleteById (no term to delete
by IIUC)
** I attempted to brute force these schemas to use "string" for the id,
expecting it might cause _some_ "false failures" (ie: if a test using one of
these schemas was depending on numeric order for sorting/range-queries on the
uniqueKeyField) but in practice there were still lots of confusing failures due
to tests expecting Numerc types for the 'id' field in returned documents.
** So instead I just made IndexSchema fail fast if someone tries to use a
PointField for uniqueKey -- this means we're still probably masking some
*other* PointField realted bugs in tests that use these schema, but my hope was
that at least the "masking" failures would now unambiguious.
That's as far as i got today -- but i plan to continue to spend a lot of time
on this next week as well.
I'm attaching my ant output from running _just_ the solr/core tests. I haven't
had a chance to dig into the results much -- but at a glance...
{noformat}
Completed [724/724 (145!)] on J0 in 0.00s, 5 tests
...
Tests with failures [seed: DA139D8A7DC075B6] (first 10 out of 207):
...
Tests summary: 724 suites (8 ignored), 2866 tests, 104 suite-level errors, 71
errors, 34 failures, 1631 ignored (85 assumptions)
$ grep -l "facet on a multivalued PointField without docValues"
../build/solr-core/test/*.xml
../build/solr-core/test/TEST-org.apache.solr.schema.TestPointFields.xml
../build/solr-core/test/TEST-org.apache.solr.TestRandomDVFaceting.xml
$ grep -l "stats on a multivalued PointField without docValues"
../build/solr-core/test/*.xml
# no matches to the last grep ... i guess we're not doing much multi-valued
numeric stats testing???
$ grep -l "nocommit: uniqueKey" ../build/solr-core/test/*.xml | wc -l
119
$ grep -L "nocommit: uniqueKey" ../build/solr-core/test/*.xml | xargs grep -L
'errors="0" failures="0"'
../build/solr-core/test/TEST-org.apache.solr.cloud.BasicDistributedZk2Test.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.DistribCursorPagingTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.DistribJoinFromCollectionTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.ForceLeaderTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.HttpPartitionTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.LeaderFailureAfterFreshStartTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.RecoveryAfterSoftCommitTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.SolrCloudExampleTest.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.TestCloudDeleteByQuery.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.TestCryptoKeys.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.TestOnReconnectListenerSupport.xml
../build/solr-core/test/TEST-org.apache.solr.cloud.TestRandomRequestDistribution.xml
../build/solr-core/test/TEST-org.apache.solr.core.TestCustomStream.xml
../build/solr-core/test/TEST-org.apache.solr.core.TestDynamicLoading.xml
../build/solr-core/test/TEST-org.apache.solr.handler.TestSolrConfigHandlerCloud.xml
../build/solr-core/test/TEST-org.apache.solr.handler.TestSQLHandler.xml
../build/solr-core/test/TEST-org.apache.solr.response.TestGeoJSONResponseWriter.xml
../build/solr-core/test/TEST-org.apache.solr.schema.TestBulkSchemaConcurrent.xml
../build/solr-core/test/TEST-org.apache.solr.schema.TestPointFields.xml
../build/solr-core/test/TEST-org.apache.solr.search.join.BlockJoinFacetDistribTest.xml
../build/solr-core/test/TEST-org.apache.solr.search.join.TestCloudNestedDocsSort.xml
../build/solr-core/test/TEST-org.apache.solr.search.TestSolr4Spatial2.xml
../build/solr-core/test/TEST-org.apache.solr.servlet.CacheHeaderTest.xml
../build/solr-core/test/TEST-org.apache.solr.TestRandomDVFaceting.xml
{noformat}
NOTE: A spot check of a few suites from that last list suggests that many of
them are still failing due to a root cause of the uniqueKey field using points
-- but that's not manifesting in the failure message for various reasons (ie:
test doesn't check if core/collection loaded/created successfully before hiting
it with queries)
Now that I have a jira# I'll create a branch to iterate on and investigating
further. The biggest priority being figuring out a quick & dirty solution to
working around the schemas using numeric uniqueKey fields -- so we can get past
the "known known" of points not working for uniqueKey and see what new failures
pop up in these tests)
(unless someone has a better idea, i'll probably script up a change to add an
explict, non-randomized, TrieFooField fieldType to any schema whose 'id' field
uses type "foo" and adjust the 'id' field to use that fieldType)
> Randomize PointFields in all tests unless explicit reason not to
> -----------------------------------------------------------------
>
> Key: SOLR-10807
> URL: https://issues.apache.org/jira/browse/SOLR-10807
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: core.test.log.txt
>
>
> We need to seriously beef up our testing of PointFields to figure out what
> Solr features don't currently work with PointFields.
> The existing Trie/Point randomization logic in SolrTestCaseJ4 is a good start
> -- but only a handful of schema files leverage it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
