[
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045181#comment-16045181
]
Hoss Man commented on SOLR-10864:
---------------------------------
The value add here is that it will allow us to much more easily/broadly
randomize the testing between Trie & Points fields. The current Trie/Points
randomization happens on a "{{<fieldType/>}} Name" basis -- ie: {{int}} vs
{{pint}}. Which means in order to be used as widely as possible...
# it can only be used in tests schemas where there are numeric types with the
expected names {{int}} (etc...)
# {{pint}} (etc...) fieldType declarations must be _added_ to all of the
eligable schemas
# *every* numeric {{<field/>}} and {{<dynamicField/>}} declaration in those
eligable schemas needs modified to use the randomized properties
...but even then we won't have "total coverage" because of existing test
schemas that declare multiple variants of Trie fields (ie: {{int}} may use
{{precisionStep="0"}} while the same schema may contain {{tint}} using
{{precisionStep="4"}} and changing all of the Integer fields to use the {{int}}
type (so it can be randomized as {{pint}}) would decrease our test coverage of
dealing with Trie fields.
Hence this suggestion: Instead of randomizing the *type* in every numeric
{{<field/>}} we can randomize the *class* in every numeric {{<fieldType/>}} and
have to worry about the unused {{precisionStep}} params causing init failures
in the tests...
* fewer changes & simpler changes to our tests schema files
** only changing the {{<fieldType/>}} definitions, not all the {{<field/>}} and
{{<dynamicField/>}} definitions
** the changes can be be a scripted regex replacement of the
{{solr.Trie(.\*)Field}} clss names -- don't need to manually inspect every
schema looking for all the diff type names (int, tint, ints, integer, int_mf,
etc...)
* which also means the {{<field/>}} and {{<dynamicField/>}} definitions in the
test schemas will be easier to read)
Any objections?
> Add static (test only) boolean to PointField indicating 'precisionStep'
> should be ignored
> -----------------------------------------------------------------------------------------
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: master (7.0)
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good
> randomized test coverage of Points fields, I'd like to add the following to
> the {{PointField}} class...
> {code}
> /**
> * <p>
> * The Test framework can set this global variable to instruct PointField
> that
> * (on init) it should be tollerant of the <code>precisionStep</code>
> argument used by TrieFields.
> * This allows for simple randomization of TrieFields and PointFields w/o
> extensive duplication
> * of <code><fieldType/></code> declarations.
> * </p>
> *
> * <p>NOTE: When {@link TrieField} is removed, this boolean must also be
> removed</p>
> *
> * @lucene.internal
> * @lucene.experimental
> */
> public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;
> /**
> * NOTE: This method can be removed completely when
> * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed
> */
> @Override
> protected void init(IndexSchema schema, Map<String, String> args) {
> super.init(schema, args);
> if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
> args.remove("precisionStep");
> }
> }
> {code}
> Then in SolrTestCaseJ4, set
> {{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class
> basis when randomizing Trie/Points (and unset \@AfterClass).
> (details to follow in comment)
--
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
