On Dec 9, 2009, at 2:46 PM, Yonik Seeley wrote: > On Wed, Dec 9, 2009 at 2:41 PM, Yonik Seeley <yo...@lucidimagination.com> > wrote: >> So... the question is, do we have a concrete alternative to this that >> is well fleshed out? > > I do, I do... just a little variant that is geo specific and hence > results in nicer names :-) > > <fieldType name="point" latSuffix="_lat" lonSuffix="_lon/> > <field name="home" type="point"/> > <dynamicField name="*_lat" type="tdouble" indexed="true" stored="false"/> > <dynamicField name="*_lon" type="tdouble" indexed="true" stored="false"/> > > <dynamicField name="*_point" type="point"/> > > home_lat > home_lon > > work_point_lat > work_point_lon > > Note: if you want the double or tripple underscore to help prevent > collisions... then you could use latSuffix="___lat" and define the > dynamic fields that way.
Additionally, how do you deal w/ a point in a 3D (or n-D) space? I just don't see why a user shouldn't be able to use the FieldType just like any other FieldType, dynamic or not. I think it is easy enough to detect name collisions and you still get all the flexibility of dynamic fields. So, for example, say I was modeling a user and their employment history. Thus, I have a single home address plus multiple work addresses. One way of doing this would be: <field name="home" type="point"/> <dynamicField name="work_*" type="point"/> And that should all just work. The user would just ever deal w/ "home" or "work_*", but not have to deal w/ home___0 or whatever unless they really truly wanted to and even then I am not sure it is needed. How would you do this with what is proposed above? Seems like you'd have a whole proliferation of fields. Also, I don't see why a FieldType should have a dep. on a Field. Having a dependency on another FieldType seems reasonable, but I'm not sure about on a Field.
