: > 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? : : The first field would be named location__location. : The second field would be named location_home_location_home. : The third field would be named location_work_location_work.
I'm not understanding your answer -- the whole point of this example is that this hypothetical PolyField example is that for each field the user knows about, it's builting up a "lat" and a "lon" field under the covers -- my question is what real, under the covers, names do you suggest be created from teh type of configuration you suggested? : > <field name="other_location" type=latlon"/> : > <dynamicField name="*_dynamic_location" type=latlon"/> : > : > ...then what field names would be created under the covers? : > : : In general, it would be FieldType#getPattern().stripOffEndRegexStarStuff() + : Field#getName(). ...that still feels a lot more obscure then letting the <field> declaration control things -- because as a schema creator i not only have to check that the field name i want to add doesn't conflict with an existing field name (or dynamicField name glob) but i also have to check that it doesn't conflict with a pattern in a PolyField <fieldType> declaration. why make people check too things when using dynamicFields is something they already understand? : Well if this feels wrong to you then I think the schema.xml file that ships : with SOLR should also feel wrong as well because it uses the exact same : pattern for defining field type variations. That is, differences between : FieldType representations for ints and tints are not stored as variations on : the SchemaField definition itself but they are stored as variation on the : FieldTypes (e.g., a different precisionStep in the case of int [0] versus : that of tint [8]). Based on what you are proposing, why isn't precisionStep : an attribute on <field, rather than <fieldType in those examples? There's a huge differnet there -- nothing in a <fieldTYpe/> declaration right now has any influence what so ever on the ultimate "name" of the fields used -- <field/> declaration's can inherit a lot of stuff from <fieldType/> but we've never let the <fieldType/> influence the name. In an existing solr schema, i can have a list of <fieldType/>s and i can have a list of <field/>s that refrence those fieldType's by name -- and i can tweak the settings on those things laregly independently (as long as i reindex) ... but i never have to wworry that tweaking the setting of fieldType might completley break an index by causing the underlyling name of some <field name="a".../> to suddenly collide with some other <field name="a__a" .../> : Possibly. It's also a lot less traceable. It's implicit versus explicit, : which I'm not sure leads to simplicity in the end. I feel the exact opposite actaully. Saying "these PolyField types will create multiple fields under the covers, and you have to use them as <dynamicFields/> do control what names they use" seems a lot more explict and easily tracable then "these PolyField types will create multiple fileds under the covers, so you specify a pattern when you declare them, and then when you declare fields or dynamicFields that use them the following rule(s) will be applied to generate the underlying field names, so remember this rule when naming other fields to prevent conflicts". -Hoss
