Hi, There is some standardization of the syntax and semantics of range queries, function queries and sorting that exists outside of the field types themselves though. For example for range queries FieldType expects there is just 2 values that define the range I think. Thats a requirement that is enforced by the Query Parser.
By allowing each FieldType to have its own search semantics, you are going to have to let them do their own parsing too. For Grant's example of a PlusMinus kind of field, its possible to support it through term query like syntax so no custom parsing has to occur, but for other types of fields that have multiple fields, that might not be possible. In these situations is a custom Query Parser going to be necessary? On Sat, Nov 28, 2009 at 4:35 PM, Yonik Seeley <yo...@lucidimagination.com>wrote: > On Sat, Nov 28, 2009 at 9:41 AM, Chris Male <gento...@gmail.com> wrote: > > Aren't search semantics the responsibility of a Query Parser and Querys > > themselves? Just as the semantics of boolean queries are handled by the > > standard Query parsers and BooleanQuery. > > At a certain point, one needs polymorphic behavior to do the right > thing (unless you hard-code all field type info into the query > parser). This is already done via fieldType to control how range > queries, function queries, sort fields, etc, are created. > > We *could* encode all of the info for both lat/lon in a single field, > but it would be more work since Lucene fieldcaches, numeric range > queries, etc, don't support that. Practically, it seems easiest to > allow a single fieldType to use more than one internal field. > > -Yonik > http://www.lucidimagination.com >
