there was a bug where if the circle described by the point
distance query crossed the poles, then we incorrectly built
a box around it. this resulted in incorrect searh results.
When performing a MultiSearch, we create child SearchRequests
from the original SearchRequest. In doing so we copy many fields.
But, copying of the SortOrder was incorrect, as this contains
state, and distint SortOrder objects must be used. This change
introduces a Copy() method to the SearchSort interface, and
to the SortOrder types. MultiSearch now creates a new copy of
the SortOrder for each child request.
The term range query is not often used in full-text queries, but
can be useful when filtering on keyword indexed text terms in
the index.
The JSON syntax to do a TermRange query is the same as for
NumericRange, but the min/max values must be string and not
float64.
- TermSearcher has alternate constructor if term is []byte, this can avoid
copying in some cases. TermScorer updated to accept []byte term. Also
removed a few struct fields which were not being used.
- New MultiTermSearcher searches for documents containing any of a list of
terms. Current implementation simply uses DisjunctionSearcher.
- Several other searcher constructors now simply build a list of terms and
then delegate to the MultiTermSearcher
- NewPrefixSearcher
- NewRegexpSearcher
- NewFuzzySearcher
- NewNumericRangeSearcher
- NewGeoBoundingBoxSearcher and NewGeoPointDistanceSearcher make use of
the MultiTermSearcher internally, and follow the pattern of returning
an existing search.Searcher, as opposed to their own wrapping struct.
- Callback filter functions used in NewGeoBoundingBoxSearcher and
NewGeoPointDistanceSearcher have been extracted into separate functions
which makes the code much easier to read.
- make geo queries accessible from top-level bleve
- update query parsing to support same geo point formats as
document parsing
- add constructor for easier sorting by geo distance in Go
- additional integration tests using alternate (GeoJSON) style points
also added flag for bounding box searcher to optionally not
check boundaries. this is useful when other searchers are going
to check every point anyway by some other criteria.
- added readme pointing back to lucene origins
- improved documentation of exported methods in geo package
- improved test coverage to 100% on geo package
- added support for parsing geojson style points
- removed some duplicated code in the geo bounding box searcher
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.
previously we parsed/returned large sections of the documents
back index row in order to compute facet information. this
would require parsing the protobuf of the entire back index row.
unfortunately this creates considerable garbage.
this new version introduces a visitor/callback approach to
working with data inside the back index row. the benefit
of this approach is that we can let the higher-level code
see values, prior to any copies of data being made or
intermediate garbage being created. implementations of
the callback must copy any value which they would like to
retain beyond the callback.
NOTE: this approach is duplicates code from the
automatically generated protobuf code
NOTE: this approach assumes that the "field" field be serialized
before the "terms" field. This is guaranteed by our currently
generated protobuf encoder, and is recommended by the protobuf
spec. But, decoders SHOULD support them occuring in any order,
which we do not.
Marty Schoch