lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject RE: SOLR-1131 - Multiple Fields per Field Type
Date Mon, 07 Dec 2009 22:59:12 GMT

: <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.


View raw message