lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: SOLR-1131 - Multiple Fields per Field Type
Date Sun, 29 Nov 2009 00:37:01 GMT

: 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 


View raw message