On Dec 7, 2009, at 5:59 PM, Chris Hostetter wrote: > > : <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...
Have a look at the patch I put up today. I think it is going to work quite well, but that could be jet-lag induced delirium at this point. For a field type: <fieldType name="point" type="solr.PointType" dimension="2" subFieldType="double"/> and a field declared as: <field name="home" type="point" indexed="true" stored="true"/> And a new document of: <doc> <field name="point">39.0 -79.434</field> </doc> There are three fields created: home -- Contains the stored value home___0 - Contains 39.0 indexed as a double (as in the "double" FieldType, not just a double precision) home___1 - Contains -79.434 as a double > > <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 agree. It requires more configuration and more knowledge by the end user and doesn't hid the details.
