[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944282#comment-13944282
]
Steve Rowe edited comment on SOLR-5228 at 3/23/14 12:27 AM:
------------------------------------------------------------
Hi Erick,
Patch looks fine, except, as Robert said earlier:
{quote}
Can we just go the simple route of deprecating 'fields' and 'types' in 4.x
(throw error in 5.x), and in 4.x also allow field/fieldtypes to be "top-level"
in the schema.
I think this is ultimately simpler than just willy-nilly allowing shit to be
nested underneath anywhere: thats hard to maintain:
{quote}
Your XPath changes in {{IndexSchema}} willy-nilly allow (dynamic)field /
fieldType to be nested underneath anywhere:
{noformat}
465: // ../fieldType or fieldtype
466: expression = "//" + FIELD_TYPE + XPATH_OR + "//" +
FIELD_TYPE.toLowerCase(Locale.ROOT);
[...]
638: // ../field | /schema/dynamicField
639: String expression = "//" + FIELD + XPATH_OR + "//" + DYNAMIC_FIELD;
640: NodeList nodes = (NodeList)xpath.evaluate(expression, document,
XPathConstants.NODESET);
{noformat}
I think we should keep the old XPath and *add* ones allowing top-level
versions, something like (untested) the following (after putting back the TYPES
constant):
*edit* reordered the XPath alternatives to have the old-school versions last
{noformat}
466: // /schema/fieldtype | /schema/fieldType |
/schema/types/fieldtype | /schema/types/fieldType
467: expression = stepsToPath(SCHEMA, FIELD_TYPE.toLowerCase(Locale.ROOT))
// backcompat(?)
468: + XPATH_OR + stepsToPath(SCHEMA, FIELD_TYPE)
469: + XPATH_OR + stepsToPath(SCHEMA, TYPES,
FIELD_TYPE.toLowerCase(Locale.ROOT))
470: + XPATH_OR + stepsToPath(SCHEMA, TYPES, FIELD_TYPE);
[...]
642: // /schema/field | /schema/dynamicField |
/schema/fields/field | /schema/fields/dynamicField
643: String expression = stepsToPath(SCHEMA, FIELD)
644: + XPATH_OR + stepsToPath(SCHEMA, DYNAMIC_FIELD)
645: + XPATH_OR + stepsToPath(SCHEMA, FIELDS, FIELD)
646: + XPATH_OR + stepsToPath(SCHEMA, FIELDS, DYNAMIC_FIELD);
{noformat}
was (Author: steve_rowe):
Hi Erick,
Patch looks fine, except, as Robert said earlier:
{quote}
Can we just go the simple route of deprecating 'fields' and 'types' in 4.x
(throw error in 5.x), and in 4.x also allow field/fieldtypes to be "top-level"
in the schema.
I think this is ultimately simpler than just willy-nilly allowing shit to be
nested underneath anywhere: thats hard to maintain:
{quote}
Your XPath changes in {{IndexSchema}} willy-nilly allow (dynamic)field /
fieldType to be nested underneath anywhere:
{noformat}
465: // ../fieldType or fieldtype
466: expression = "//" + FIELD_TYPE + XPATH_OR + "//" +
FIELD_TYPE.toLowerCase(Locale.ROOT);
[...]
638: // ../field | /schema/dynamicField
639: String expression = "//" + FIELD + XPATH_OR + "//" + DYNAMIC_FIELD;
640: NodeList nodes = (NodeList)xpath.evaluate(expression, document,
XPathConstants.NODESET);
{noformat}
I think we should keep the old XPath and *add* ones allowing top-level
versions, something like (untested) the following (after putting back the TYPES
constant):
{noformat}
466: // /schema/fieldtype | /schema/fieldType |
/schema/types/fieldtype | /schema/types/fieldType
467: expression = stepsToPath(SCHEMA, TYPES,
FIELD_TYPE.toLowerCase(Locale.ROOT)) // backcompat(?)
468: + XPATH_OR + stepsToPath(SCHEMA, TYPES, FIELD_TYPE)
469: + XPATH_OR + stepsToPath(SCHEMA, FIELD_TYPE.toLowerCase(Locale.ROOT))
470: + XPATH_OR + stepsToPath(SCHEMA, FIELD_TYPE);
[...]
642: // /schema/field | /schema/dynamicField |
/schema/fields/field | /schema/fields/dynamicField
643: String expression = stepsToPath(SCHEMA, FIELDS, FIELD)
644: + XPATH_OR + stepsToPath(SCHEMA, FIELDS, DYNAMIC_FIELD)
645: + XPATH_OR + stepsToPath(SCHEMA, FIELD)
646: + XPATH_OR + stepsToPath(SCHEMA, DYNAMIC_FIELD);
{noformat}
> 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: Erick Erickson
> Attachments: 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
