[ 
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050698#comment-16050698
 ] 

ASF subversion and git services commented on SOLR-10834:
--------------------------------------------------------

Commit 8f1043840f38533864b2c713daf066b6c3509147 in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8f10438 ]

Merge branch 'master' into jira/SOLR-10834


> 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.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to