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

Alexandre Rafalovitch commented on SOLR-10241:
----------------------------------------------

This all depends on what you want to achieve and work backwards from it. The 
scenario is that somebody does not want managed schema? Why? For security? They 
can lock it down. For legacy reasons? Then they already know enough Solr. 
Because many tutorials on the web still talk about old-style? Maybe there is a 
need for "upgrade" manual page or blog post.

It may be that we really should just do a manual page that is dedicated to this 
topic and its trade-off. And mention it in the config file. Or we could do a 
minimal example.

But the right way to think about it - I feel - would be backwards from the 
typical scenario.



> 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]

Reply via email to