[
https://issues.apache.org/jira/browse/SOLR-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900226#comment-15900226
]
David Smiley commented on SOLR-10241:
-------------------------------------
I sympathize with our users on this matter; there are various feature gaps that
stand in the way of managed schema being the one best way to do things
([~noble.paul] [~varunthacker] and I recently white-boarded the remaining
ones). Since that ideal reality isn't here today, I wish we had a better
out-of-the-box experience for users that want to use classic schema.
* Perhaps one approach is for bin/solr to automate conversion from managed
schema to classic, provided the user adds an option?
* I kinda dread yet another config around here to maintain; but I certainly
won't stand in anyone's way from doing so if that's how Erick (or whoever) puts
forth their time to help users. It's possibly the easiest (least work) path in
the short term, but with longer term annoyances.
* I wish the current config mechanism was more universal to both: edit a
schema.xml if you want, or purely use schema API if you want to do that. I
understand that we don't want Solr to clobber a user's changes, and so that
concern led to where we are today. One possible way to do this would be for
the schema.xml file to contain an embedded hash of the schema (less the hash
itself of course). It'd be optional and maybe have an explicit value a user
could provide to give Solr permission to overwrite it (i.e. in no event should
users calculate the hash themselves). It would only be verified when an API
based change attempts to overwrite a config.
> 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]
