[
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-10864:
----------------------------
Attachment: SOLR-10864.patch
bq. +1, I like how it'll be standardized, simplified (fieldtypes only instead
of fields; and fewer fields) and (more) comprehensive than the current setup.
Thanks -- I was second guessing myself and needed outside eyes to tell me if i
was over thinking things.
bq. How about introducing a new (independently) randomized sysprop usable as
docValues="${solr.tests.numeric.docvalues}"? Tests that need it to be one way
or the other can set it in a @BeforeClass-annotated static method.
That's a great idea -- but In the attach patch I tried to tweak your idea
slightly to "improve" it by being
{{docValues="$\{solr.tests.numeric.points.dv}"}}. When Triefields are choosen
it's always false, when points fields are choosen _then_ it will randomly be
selected. So depending on your test/config...
* Always need DV regardless of underlying type...
** Use {{docValues="true"}} in the schema
* Know you are doing something that requires DV if the numerics are points...
** {{System.setProperty("solr.tests.numeric.points.dv", "true");}} in your setup
* Know that DVs shouldn't matter for your test...
** {{docValues="$\{solr.tests.numeric.points.dv}"}}
...but actually in hindsight, I think your idea is just plain objectively
better, because it would keep the usage simpler...
* (almost) every numeric field type should have
{{docValues="$\{solr.tests.numeric.dv}"}}
* Always need DV regardless of underlying type...
** {{System.setProperty("solr.tests.numeric.dv", "true");}} in your test setup
* Know you are doing something that requires DV if the numerics are points...
** in Setup... {code}
if (Boolean.getBoolean("solr.tests.numeric.points") {
System.setProperty("solr.tests.numeric.dv", "true");
}
{code}
* Know that it shouldn't matter for your test...
** Do nothing, baseclass has already randomized
Sound Good?
---
As things stand now, the patch cleans up all tests/schemas to use the (current)
variables, with the neccessary fixes / System.setProperty /
@SuppressPointFields to tests that had assumptions/expectations about types.
There's a handful of nocommits, that generally fall into 4 categories...
* javadocs in SolrTestCaseJ4
* notes to file/fix (2) independent bugs
* randomize the variables that i currently hardcoded for forcing points testing
* notes in schema files to remove explict Point field types and update the
affected tests
** I'm actually thinking that this should really be done as a distinctly
seperate jira after we change the randomization logic
one other question I had was about changing the semantics of the current
{{solr.tests.preferPointFields}} users can set ... it can currently only be
used to "prefer points" for tests that don't have {{\@SuppressPointFields}},
but I think it would be better to change that to
{{solr.tests.use.numeric.points}} such that the semantics are:
* if {{\@SuppressPointFields}} use trie fields
* else: if user set {{-Dsolr.tests.use.numeric.points=foo}}
** if {{foo==true}} force points, else force trie
* else: randomly pick between trie and points
any objections?
----
My next steps unless someone has concerns...
# change the DV sys prop name/usage as mentioned above
# file/fix the two nocommits related to new jiras
# create a new subtask of SOLR-10807 to deal with auditing/removing most of the
hardcoded {{solr.FooPointFields}} and related fields (after the randomization
work has been rolled out to _all_ schemas and remove those nocommits from these
schema files)
# fix the jdoc & hardcoded sysprop related nocommits
> 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)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch
>
>
> (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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
