[jira] [Commented] (SOLR-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

["Erick Erickson (Jira)" <ji...@apache.org>]

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

Erick Erickson commented on SOLR-10229:
---------------------------------------

I really don't see how to make forward progress on this. I've certainly lost interest. I think the major stumbling block for me is that we'd move from a bewildering array of configurations to having code duplicated in lots and lots of tests. All without actually making Solr more robust

We'd also be encouraging two different ways of creating schemas, with all the problems attendant on keeping them in sync. True, we have that now, but not very many tests change the schemas; let's not add more without good purpose.

Consider adding a new attribute to a type ("uninvertible" or the points based numerics). Yes, it's a total pain to change a bunch of managed-schema or schema.xml files, OTOH it wouldn't be a picnic to find all the places where code in tests adds a type. Neither is attractive but having lots of both is worse yet.

So this feels like a lot of effort for not much good. If we're really going to do something about this, I think we need changes on the architectural level rather than piecemeal changes like this. What those changes would be I haven't a clue.

I propose just closing this as "won't fix" and I will do so next Tuesday (30-June). If people want to keep it around and open, I'm fine with just unassigning it or someone else can assign it to themselves.

> See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-10229
>                 URL: https://issues.apache.org/jira/browse/SOLR-10229
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Minor
>         Attachments: SOLR-10229-straw-man.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch
>
>
> The test schema files are intimidating. There are about a zillion of them, and making a change in any of them risks breaking some _other_ test. That leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen parameter to some tokenizers. Putting those parameters into any of the existing schemas, especially to test < 255 char tokens is virtually guaranteed to break other tests, so the only safe thing to do is make another schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than creating a new static schema file and it's not hard. WDYT about making this into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before putting much effort into it. I expect that the utility methods would eventually get a bunch of canned types. It's reasonably straightforward for primitive types, if lengthy. But when you get into solr.TextField-based types it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less convenient than just having _some_ canned schemas we can use. And erroneous schemas to test failure modes are probably not very good fits for any such framework.
> [~steve_rowe] and [~hossman_lucene@fucit.org] in particular might have something to say.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org