[
https://issues.apache.org/jira/browse/SOLR-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900110#comment-15900110
]
Erick Erickson commented on SOLR-10241:
---------------------------------------
>From the user's list, points to clarify in the ref guide:
I would second that guide could be clearer on that. I read and reread several
times trying to get my head around the schema.xml/managed-schema bit. I came
away from first cursory reading with the idea that managed-schema was mostly
for schema-less mode and only after some stuff ups and puzzling over comments
in the basic-config schema file itself did I go back for more careful re-read.
I am still not sure that I have got all the nuances. My understanding is:
If you don’t want ability to edit it via admin UI or config api, rename to
schema.xml. Unclear whether you have to make changes to other configs to do
this. Also unclear to me whether there was any upside at all to using
schema.xml? Why degrade functionality? Does the capacity for schema.xml only
exist for backward compatibility?
If you want to run schema-less, you have to use managed-schema????? (I didn’t
delve too deep into this).
In the end, I used basic-config to create core and then hacked managed-schema
from there.
I would have to say the "basic-config" seems distinctly more than basic. It is
still a huge file. I thought perhaps I could delete every unused field type,
but worried there were some "system" dependencies. Ie if you want *target type
wildcard queries do you need to have text_general_reverse and a copy to it? If
you always explicitly set only defined fields in a custom indexer, then can you
dump the whole dynamic fields bit?
> 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]
