[SOLR-10834] test configs should be changed to stop using numeric based uniqueKey field

• Type: Test
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 6.7, 7.0
• Labels: numeric-tries-to-points
• Assignee: Chris M. Hostetter
• Reporter: Chris M. Hostetter
• Created: 07/Jun/17 00:49
• Updated: 08/Jun/19 15:23
• Resolved: 15/Jun/17 18:00

Description

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...)

Issue Links

• relates to: SOLR-10829 IndexSchema should enforce that uniqueKey field must not be points based
• relates to: SOLR-10807 Randomize PointFields in all tests unless explicit reason not to