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