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.
