[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944953#comment-13944953
]
Erick Erickson commented on SOLR-5228:
--------------------------------------
bq: Allow the person extending the schema to provide a, well, extended schema.
Now, in order to run, we either have to
1> incorporate each and every extension anyone in the world wants to write into
our releases
or
2> require everyone who doesn't want to/can't give their extension back to
Apache to maintain their own DTD forevermore, updating it at each release of
Solr they want to upgrade.
Don't get me wrong, I have complete and total sympathy with the end goal here.
If we can solve this in a way that extends we could save users countless hours,
your point about multivalued .vs. multiValued is well taken indeed. I suppose
trading that off against the added pain caused by invalidating current tools is
a judgement call.
And I don't know that much about extending DTDs. Is there a way to do something
similar to xinclude? Or shutting off validation. Hmmm, I rather like that one
at first glance, although I'm not sure where to specify it. Perhaps a default
of on, expert users could turn validation off if they added custom stuff or
decide to keep their own copy of the DTD up to date.
How much you want to bet the first time we tried to run tests we'd find some of
our test schemas have errors?
> Deprecate <fields> and <types> tags in schema.xml
> -------------------------------------------------
>
> Key: SOLR-5228
> URL: https://issues.apache.org/jira/browse/SOLR-5228
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Reporter: Hoss Man
> Assignee: Erick Erickson
> Fix For: 4.8, 5.0
>
> Attachments: SOLR-5228.patch, SOLR-5228.patch
>
>
> On the solr-user mailing list, Nutan recently mentioned spending days trying
> to track down a problem that turned out to be because he had attempted to add
> a {{<dynamicField .. />}} that was outside of the {{<fields>}} block in his
> schema.xml -- Solr was just silently ignoring it.
> We have made improvements in other areas of config validation by generating
> statup errors when tags/attributes are found that are not expected -- but in
> this case i think we should just stop expecting/requiring that the
> {{<fields>}} and {{<types>}} tags will be used to group these sorts of
> things. I think schema.xml parsing should just start ignoring them and only
> care about finding the {{<field>}}, {{<dynamicField>}}, and {{<fieldType>}}
> tags wherever they may be.
> If people want to keep using them, fine. If people want to mix fieldTypes
> and fields side by side (perhaps specify a fieldType, then list all the
> fields using it) fine. I don't see any value in forcing people to use them,
> but we definitely shouldn't leave things the way they are with otherwise
> perfectly valid field/type declarations being silently ignored.
> ---
> I'll take this on unless i see any objections.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
