Provide default string-based field for schema field types unknown to Sunburnt #66

merged 1 commit into from Dec 24, 2012


None yet
3 participants

davidjb commented Dec 18, 2012

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 -- 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.


tow commented Dec 18, 2012

Looks very good, and very useful, thanks.

Can you rebase so the patch applies against current master?

@davidjb davidjb 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).



davidjb commented Dec 19, 2012

Rebased and ready to go.

@tow tow added a commit that referenced this pull request Dec 24, 2012

@tow tow Merge pull request #66 from davidjb/default-field-type
Provide default string-based field for schema field types unknown to Sunburnt

@tow tow merged commit d349317 into tow:master Dec 24, 2012

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment