[ https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049470#comment-16049470 ]
Hoss Man commented on SOLR-10834: --------------------------------- bq. I am however still seeing some fairly consistent failure from SuggesterTest and it's subclasses ... I can not for the life of me explain how SuggesterTest manages to pass on master -- it has some wacky "reload the core" logic in {{testReload()}} that winds up creating a new core with the default {{solrconfig.xml}} and {{schema.xml}} instead of the {{*-spellchecker.xml}} files the core was originally using, and that new core with it's totally not the correct config/schema can wind up being used in other test methods that come later. Somehow, on master, where {{schema.xml}} was using an "int" id field this didn't manage to cause any failures, but in our SOLR-10834 branch where both schemas agree that "id" is a string we get problems. I ripped out most of this hooky "reload" code and replaced it with {{TestHarness.reload()}} and all is right with the world. At present, all tests & precommit pass on the branch ... i'll aim to squash merge it with master tomorrow. > 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