Hi All, >> >> : <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...
+1. > >> 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. > +1 to that, as well. I had mentioned in an earlier thread about using the APIs and code to perform such a check. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
