[
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041208#comment-16041208
]
Hoss Man commented on SOLR-10834:
---------------------------------
bq. I realize it's orthogonal to this JIRA, but if we're going to look at
schemas in bulk I thought I'd mention it.
I appreciate the mention, but honestly i don't see how we can save work by
trying to tackle both at the same time -- that seems like it would just slow
both efforts down.
* in SOLR-10229 the bulk of the work will be pruning schema files and changing
test _setup_ methods to make method calls to add what they need - that can be
done regardless of what type of uniqueKey field is used and will need to be
done on a test class by class basis.
* here the bulk of the work is in changing test _execution_ methods to _expect_
string uniqueKey fields on a test by test class basis ... mass replacing the
fieldType used by the uniqueKey field is trivial (regardless of whether it
happens before/after SOLR-10229)
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
