On Dec 9, 2009, at 2:04 PM, Chris Hostetter wrote: > > : <fieldType name="point" type="solr.PointType" dimension="2" > subFieldType="double"/> > : <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 > > Grant: All of this i understand -- the back and forth Mattmann and I have > been having is specificly about the idea that the "__0" and __1" should be > more transparent when declaring the schema. AS it stands right now, if i > add this to my schema... > > <field name="home___0" type="int" indexed="true" stored="true"/> > > ...i can really break things. The odds of that happening are probably > low, but it would still be very easy to make this type more transparent to > schema creators by requring that PolyFields be declared as dynamicFields. > so your previous example would become... > > : <fieldType name="point" type="solr.PointType" dimension="2" > subFieldType="double"/> > : <dynamicField name="home*" type="point" indexed="true" stored="true"/> > > ...now if i'm stupid enough to add <field name="home___0"/> it's my own > damn fault (just like it is right now w/o having PolyFields in Solr) > > : > 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. > > 1) My example requires 8 more characters then yours.
It's not about the characters, obviously, it's about the mindset of the person doing the modeling, hence... > 2) The "end" user doesn't need to know it's a dynamic field, they still > just deal with a field named "home" > 3) my whole point is that we shouldn't be hiding these details from the > person editing the schema.xml I'm not sure I agree. I think people would expect to use a new Field Type in exactly the same ways the use existing Field Types, namely anywhere they want (dynamic or not). We could easily validate the schema at start up time to see whether they have done the scenario you describe above and throw an exception.
