This looks reasonable. I'll take a look at the patch. Originally, I had intended that it was just for one Field Sub Type, thinking that if we ever wanted multiple sub types, that a new, separate class would be needed, but if this proves to be clean this way, then I see no reason not to incorporate it. Besides, I could see extending PointType, etc. to be NamedPointType, for example.
I'm curious, Mark, how are you searching those fields? What types of queries are you generating? -Grant On Jul 2, 2010, at 9:51 AM, Mark Allan wrote: > Hi folks, > > I've made a few small changes to the AbstractSubTypeFieldType class to allow > users to define distinct field types for each subfield. This enables us to > define complex data types in the schema. > > For example, we have our own subclass of the CoordinateFieldType called > TemporalCoverage (I've spoken about this recently on the mailing list) where > we store a start and end date for an event but now we can store a name for > the event as well. > > <fieldType name="temporal" class="uk.ac.edina.solr.schema.TemporalCoverage" > dimension="3" subFieldSuffix="_ti,_ti,_s"/> > > In this example, the start and end dates get stored as trie-coded integers > and the description as a string. > > As usual, it's up to your own subclass to do sanity checking on the input to > ensure the right number and type of subfields are there in the document field. > > We now store documents like this: > <doc> > <field name="id">15250</field> > <field name="name">Events of the 20th Century</field> > <field name="description">Film covering a variety of important events in the > 20th Century.</field> > <field name="daterange">1914,1918, First World War</field> > <field name="daterange1">1939,1945, Second World War</field> > <field name="daterange2">1957,1969, Space Race</field> > <field name="daterange3">1990,2000, random date</field> > ... > </doc> > > The changes to AbstractSubTypeFieldType do not have any adverse effects on > the solr.PointType class, so I'd quite like to suggest it gets included in > the main solr source code. Where can I send a patch for someone to evaluate > or should I just attach it to the issue in JIRA and see what happens? > https://issues.apache.org/jira/browse/SOLR-1131 > > Mark > > PS. Is the solr-dev mailing list dead? There's nothing in the archives since > April. > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. >
