Hoss Man created SOLR-10834:
-------------------------------
Summary: test configs should be changed to stop using numeric
based uniqueKey field
Key: SOLR-10834
URL: https://issues.apache.org/jira/browse/SOLR-10834
Project: Solr
Issue Type: Test
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Apparently, once upon a time, as a way to prove that it worked and there were
no hard coded "String" assumptions, some the {{schema.xml}} used by tests was
written such that the uniqueKey field was definied as an "int".
This has now snowballed such that there are at least 40 test schema files (just
in solr/core!) that define the uniqueKey field using a Trie field (mostly
TrieInt, but at least 2 TrieFloats!) despite the fact that at no point have we
ever recommended/encouraged people to use anything other then StrField for
their uniqueKey.
that's nearly 1/3 of all the test schemas that we have -- which IIRC (from some
early experiments in SOLR-10807) are used in more then half the solr/core tests.
If we want to be able to deprecate/remove Trie fields in favor of point fields,
we're really going to update all of these test schemas to use a StrField (we
can't use PointFields as the uniqueKey due to the issues noted in SOLR-10829)
... but AFAICT that's going to require a non trivial amount of work due to many
of these tests making explicit/implicit assumptions about the datatype of the
uniqueKey field (ex: sorting by id, range queries on ids, casting stored field
values returned by solrj, xpath expressions, etc...)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
