[
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
Before diving in completely, here's a starting point patch for discussion to
(that's a bit cleaner to follow then everything i've hacked up in the
SOLR-10807 branch).
it updates _most_ of the schema files that were using the old points
randomization sysprops (i just realized i missed a couple) to use the newer
style i was suggesting as well as adding
{{docValues="$\{solr.tests.numeric.points\}"}} as a demo of what i had in mind
regarding Tomas's recent comment (in the SOLR-10807 branch i hacked around this
problem a diff way). One thing didn't spend any time on yet is ripping out
some of the explicit points based fields/dynamicFields from these schemas.
Assuming we go forward with this approach, we could then expand it ot cover all
the schemas - such that nothing ever defined a {{solr.TrieIntField}}
There are still a bunch of test failures with this patch -- most either because
of tests that should be subclassing SOlrTestCaseJ4 but shouldn't for silly
reasons (but i didn't put defaults in for the sysprops because i wanted to help
shake out bugs) or because of legit problems with points that we know about
that we can either update with \@SuppressPoints or disable piecemeal with
{{assumeFalse(Boolean.getBoolean("solr.tests.numeric.points"))). The patch
includes a handful of examples of this.
Honestly: I'm a little disappointed at how much i had to leverage
{{docValues="$\{solr.tests.numeric.points\}"}} ... i was hoping that only a
handful of facet/stats related schemas would need that, but so many tests relay
on the same schema files I worry we''ll essentially have to put it every where,
and we'll wind up under testing points fields with {{docValues="false"}}
[~tomasflobbe] & [~steve_rowe]: You guys have spent a lot of time working
on/with points randomized tests -- what do you think? Is this approach "less
bad/cubersome/anoying" then the current way we randomize in points?
> 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
>
>
> (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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
