[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762497#comment-13762497
]
Erick Erickson commented on SOLR-5228:
--------------------------------------
not very far below where fieldType and fields are parsed out with a path that
includes <types> or <fields> there's this bit for copyField:
expression = "//" + COPY_FIELD;
nodes = (NodeList) xpath.evaluate(expression, document,
XPathConstants.NODESET);
for (int i=0; i<nodes.getLength(); i++) {
I happened to run into this because a customer put <copyField> tags inside the
<fields> tag and it worked which surprised me at the time....
Seems like the model we could use, we wouldn't even need to formally deprecate
the <types> or <fields> tags, just comment that they were no longer necessary.
FWIW
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
