On Nov 28, 2009, at 7:37 PM, Chris Hostetter wrote:
>
> : I don't think it's useful to somehow programmatically access the list
> : of fields that a fieldType could output.
>
> based on my understanding of the potential types of use cases we're
> talking about, i think i agree with you. It seems like the most crucial
> aspect is that a FieldType has a way of producing multiple
> o.a.l.document.Field instances (potentially with different field names)
> from a single String input at index time. this can be done with something
> like the API that Grant mentioned earlier.
>
> For anything except non-trivial use cases, any code (like a query parser)
> attempting to deal with this fields is going to need to be very special
> purpose and have direct knowledge of the code in the FieldType. if a
> "CartesienGeoSearchQParser" is asked to parse
> "store_location:89.3,45.4~5miles" it can throw a parse exception if
> IndexSchema.getFieldType("store_location") isn't an instanceof
> "CartesianGeoSearchFieldType" -- assuming it is: it can cast it and call
> CartesianGeoSearchFieldType specific methods to find out everything it
> needs to know about what multitudes of field names that specific instance
> produced based on it's configuration. (side thought: we may want to add a
> "getFieldTypesByClass" method to the IndexSchema so QParsers and
> SearchComponents can get lists of fields matching special cases they want
> to know about -- but that's a secondary concern)
>
> One thing that concerns me is potential field name collision -- where one
> of these new multifield producing FieldTypes might want to creat a name
> that happens to collide with a field the user has already declared.
>
> Using Double underscores kind of feels like a hack, what i keep wondering
> is if we can't leverage dynamicFields here. if we require that these
> FieldTypes be declared using <dynamicField> delcarations (they could error
> on init otherwise) then the wildcard nature of the name tells the
> FieldType where it's allowed to add things to the pattern to make unique
> field names in the index -- and they can still be used as true dynamic
> fields, as long as they always add to the field name given to them.
> something like...
>
> <dynamicField name="location*" type="geo1" />
I thought about this too. It is what Local Solr currently does (although it
expects a certain prefix, too, I believe). However, it seems a bit
unnecessary, as now the user needs to use both the field type and the dynamic
field in order to get it to work, whereas I don't think they should have to do
that, as it isn't in line with the notion of a field type. FieldTypes
currently can be used for any fields, both regular and dynamic.
