Hi Erick, The field type for LatLonType mandates a subFieldSuffix or subFieldType attribute, and so I think there’s clearly a problem if you don’t provide a field type that’s going to match it. The default schema even has a comment on the dynamicField definition for *_coordinate that it’s needed. I think this is enough but if you want to improve the situation further, be my guest.
By the way, next time title the subject appropriately and then CC me if you want to ensure I see it. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Tue, Aug 5, 2014 at 4:53 PM, Erick Erickson <erickerick...@gmail.com> wrote: > Just had a situation where searching on a successfully indexed document > with a location type field errored out. It turns out that the problem was > the following: > > 1> the user removed the *_coordinate dynamic field definition > 2> the user had the universal ignore dynamic field un-commented, as: > <dynamicField name="*" type="ignored" multiValued="true" /> > > > So, (and I'm guessing a bit here) the underlying code for adding the > lat/lon as location_1_coordinate and location_0_coordinate did its thing, > and then the document was successfully added to the index... by throwing > location_1_coordinate and location_0_coordinate on the floor. So of course > when he tried to use bbox (in an fq clause in this case) he got an error > message about requiring indexed fields to work from. > > The long and short of it is whether it's worth opening a JIRA? Something > like "geospatial should check dynamic field definitions and fail if they > aren't properly defined"? If so, I''ll do it. > > Thanks! > Erick > >
