: <fieldType name="latlon" type="LatLonFieldType" pattern="location__*" /> : <fieldType name="latlon_home" type="LatLonFieldType" pattern="location_home_*"/> : <fieldType name="latlon_work" type="LatLonFieldType" pattern="location_home_*"/> : : <field name="location" type=latlon"/> : <field name="location_home" type=latlon_home"/> : <field name="location_work" type=latlon_work"/>
I'm not really understanding the value of an approach like that. for starters, what Lucene field names would ultimately be created in those examples? And if i also added... <field name="other_location" type=latlon"/> <dynamicField name="*_dynamic_location" type=latlon"/> ...then what field names would be created under the covers? : I think it makes more sense to define the heterogeneity at the fieldType level because: : : (a) it's a bit more consistent with the existing solr schema examples, : where the difference between many of the field types (e.g., ints and : tints, which are both solr.TrieIntField's, date and tdate, both : instances of solr.TrieDateField, with different configuration, etc.) : : (b) isolation of change: <fieldType> defs will change less often than : <field> defs, where names and indexed/stored/etc. debugging are likely : to occur more frequently ...this just feels wrong to me ... i can't really explain why. It seems like you are suggesting thatt every <field/> declaration would need a one to one corrispondence with a unique <fieldType/> declaration in order to prevent field name collisions, which sounds sketchy enough ... but i'm also not fond of the idea that a person editing the schema can't just look at the <field/> and <dynamicField/> names to ensure that they understand what underlying fields are being created (so they don't inadvertantly add a new one that collides) ... now they also have to look at the "pattern" attribute of every <fieldType/> that is a poly field. letting <dynamicField/> drive everything just seems a *lot* simpler ... both as far as implementation, and as far as maintaining the schema. : I don't think the above hybrid approach will lead to anything other than : confusion, as you indicated above. Let's stick to the pattern defs at : the <fieldType> level, and then let the fieldType handle the internal : "dynamicity" with e.g., a dynamicField, and then notify the schema user >From the standpoint of reading a schema.xml file, the approach you're describing of a pattern attribute on <fieldType/> declarations actaully seems more confusing then the strawman suggestion i made of a pattern attribute on <field> ... even without understanding what concrete feilds you are suggesting would be created with a configuration like that, it still increases the number of places you have to look to see what field names are getting created. -Hoss
