[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943797#comment-13943797
]
Yonik Seeley commented on SOLR-5228:
------------------------------------
bq. Well, I don't think it's confusing if you get an error message that's clear
about the change.
What's confusing about having no error message and having it "just work"? A
user trying an older schema and having it work is less confusing than them
getting an error.
The confusion is initially *seeing* both formats and wondering what the
difference is. That confusion will exist no matter what we do (assuming we
make this change).
bq. A similar strategy was taken for example when indexDefault/indexMain were
removed from solrconfig.xml and and now that solr.xml has changed.
It's a different situation. The danger in that case was that someone would
change indexDefault and expect the changes to take effect, when in fact they
were ignored. That situation does not exist here if we do as Erick suggests
and use a copyField like pattern: expression = "//" + COPY_FIELD;
bq. Its also better in the sense that you don't need to maintain all
configuration formats variations forever
Due to the power of xpath, it's a one line change.
> Don't require <field> or <dynamicField> be inside of <fields> -- or that
> <fieldType> be inside of <types>
> ---------------------------------------------------------------------------------------------------------
>
> 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: Hoss Man
>
> 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]
