: 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" />
can be use to index a single "location" field (internal construction
"location_lat" and "location_lon" or it could be used to support a
"location_start" and "location_end" field (using
location_start_lat+location_start_lon and
location_end_lat+location_end_lon)
-Hoss
