This allows Sunburnt to function on field types it doesn't know about, using strings as values for serialisation and deserialisation (as Solr stores them).
This is helpful for fields where a Sunburnt implementation would be overly complicated and/or require extra dependencies on Sunburnt itself. One specific example is that of the recently added solr.SpatialRecursivePrefixTreeFieldType for spatial searching (see http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4#Indexing) -- this field takes a variety of different spatial descriptors (coordinates, Well-Known Text (WKT), etc), so implementing a specific field is going to be rather complicated. Using this pull request, users can work with such a field type, and do so simply using plain strings.
Without this default fall-back, Sunburnt will error when attempting to communicate with a Solr instance with a field configured that it has no field type for -- even if that field type isn't used for an actual field.
Tests and documentation about default field translations included.
Looks very good, and very useful, thanks.
Can you rebase so the patch applies against current master?
Provide default string-based field for schema field types unknown to …
This allows Sunburnt to continue to function on field types it knows nothing
about, using strings as values (as Solr stores them).
Rebased and ready to go.
Merge pull request #66 from davidjb/default-field-type
Provide default string-based field for schema field types unknown to Sunburnt
@tow I see you are also package maintainer for sunburnt on pypi.
I stumbled over this error with the SpatialRecursivePrefixTreeFieldType today and think that a lot of people starting from an example solr configuration might have the same problem, so it would be good to have something in pypi that is more recent than the current 0.6 from 2012-01-01