[jira] [Commented] (SOLR-10241) Add a configset for "classic" schema.xml.

["Alexandre Rafalovitch (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org