[ https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erick Erickson updated SOLR-5228: --------------------------------- Attachment: SOLR-5228.patch Decided to work up a patch to see what it would take. Was a little surprised by some of the work with the schema api, had to modify a few tests: [~steve_rowe] - if you have a chance, please see if I've done violence to the managed schema code I changed. There were a few changes both to code and tests. All: The "FIELDS" static in IndexSchema.java turns out to be overloaded a bit in case you're wondering why I took "types" out but left "fields" in. It's used to put together output packets as well as parse the schema.xml file. Finally, I just took some of the <fields> and <types> tags out of some of the stock test files on the theory that would test code more randomly than I would. For the final patch, I'll take the <fields> and <types> tags out of the stock distro schema.xml file(s). Let me know if there are objections, I'll commit next week if not. I hear what Robert and Tomas are saying, but in this case I don't think the hassle to the users of enforcing these tag's absence is worth it. And it would be more work for the devs I think. > 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