[
https://issues.apache.org/jira/browse/SOLR-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899892#comment-15899892
]
Alexandre Rafalovitch commented on SOLR-10241:
----------------------------------------------
Not a bad idea. In my mind it all depends on having a kitchen-sink schema from
which things can be copied. If that exists and explains the cross-dependencies
(e.g. this field definition is used in solrconfig.xml because of....), then we
can simplify other things quite a lot.
So, to me, we kind of need an umbrella issue to hash out what "kitchen sink"
could look like and then what that means going downstream. And - of course -
people willing to think about it in details, which is actually the bigger
problem.
> Add a configset for "classic" schema.xml.
> -----------------------------------------
>
> Key: SOLR-10241
> URL: https://issues.apache.org/jira/browse/SOLR-10241
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
>
> There are a number of questions on the user's list about hand-editing the
> managed-schema files. I think there's also confusion about the fact that the
> classic schema is still possible (yes, I know there's documentation, but....)
> WDYT about creating a new configset that uses classic schema factory? And
> perhaps make it pretty minimal? Just a few useful field types (text_en, the
> primitive ones, maybe with a couple with stopword files in the lang subdir).
> Just enough to show a good structure...
> Straw man candidates to remove:
> schema
> > most/all of the language variants
> > dynamic fields (maybe leave one in a comment)
> > copyField directives (maybe leave one in a comment)
> > ???
> solrconfig
> > clustering,
> > most if not all of the language variants (maybe include one or two in
> > comments).
> > QEV.
> > Take out anything that requires adding <lib> directives
> > browse request handler
> > ???
> Maybe put in a comment where to find the examples (e.g. one of the existing
> config sets).
> That said, how this squares with simplifying/cleaning up current configsets
> is a good question.
> (from on offline conversation) There are already at least 2 issues about
> cleaning up the existing ones, so this is the same behavior that gets us into
> this - we can’t agree on what good examples are so we just throw another one
> into the pile
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
