We recenlty introduced support for indexing the content of
things implementing TextMarshaler. Since often times interfaces
are implemented via pointer receivers, we added support to
introspect pointers (previously we just dereferenceed them and
traversed into their underlying structs). However, in doing so
we neglected to consider the case where the pointer does
implement the interface we care about, but happens to be nil.
fixes#603
Sometimes you have structs which contain data which isn't
exported, or for which the correct data to index isn't just the
contents of it's exported fields. In these cases your struct
can implement TextMarshaler to return a suitable text
representation.
Previously bleve did not recognize this interface and do anything
to use it. Now, if the field containing such a struct is
explicitly mapped as "text" and if the struct (or pointer to it)
implements TextMarshaler, we index a text field with the
contents returned by MarshalText().
For backwards compatibilty, dynamic mappings will never use
this feature, and will continue to traverse into the struct
and index the exported fields directly.
fixes#281
New field type GeoPointField, or "geopoint" in mapping JSON.
Currently structs and maps are considered when a mapping explicitly
marks a field as type "geopoint". Several variants of "lon", "lng", and "lat"
are looked for in map keys, struct field names, or method names.
New query type GeoBoundingBoxQuery searches for documents which have a
GeoPointField indexed with a value that is inside the specified bounding box.
New query type GeoDistanceQuery searches for documents which have a
GeoPointField indexed with a value that is less than or equal to the
specified distance from the specified location.
New sort by method "geo_distance". Hits can be sorted by their distance
from the specified location.
New geo utility package with all routines ported from Lucene.
New FilteringSearcher, which wraps an existing Searcher, but filters
all hits with a user-provided callback.
the index mapping contains some relatively messy logic
and the top-level bleve package only cares about a relatively
small portion of this
the motivation for this change is to codify the part that the
top-level bleve package cares about into an interface
then move all the details into its own package
NOTE: the top-level bleve package still has hard dependency on
the actual implementation (for now) because it must deserialize
mappings from JSON and simply assumes it is this one instance.
this is seen as OK for now, and this issue could be revisited
in a future change. moving the logic into a separate package
is seen as a simplification of top-level bleve, even though
we still depend on the one particular implementation.
abhinavdangeti