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.
- 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
as we are a Go library is this the much more natural way to
express such queries.
support for strings is still supported through json marshal
and unmarshal, as well as inside query string queries
as before we use the package level QueryDateTimeParser to
deterimine which date time parser to use for parsing
only serializing out to json, we consult a new package
variable: QueryDateTimeFormat
this addresses the longstanding PR #255
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.
parsing of date ranges in queries no longer consults the
index mapping. it was deteremined that this wasn't very useful
and led to overly complicated query syntax/behavior.
instead, applications get set the datetime parser used for
date range queries with the top-level config QueryDateTimeParser
also, we now support querying date ranges in the query string,
the syntax is:
field:>"date"
>,>=,<,<= operators are supported
the date must be surrounded by quotes
and must parse in the configured date format
having boost of 0 led to invalid scores of NaN
added integration test for wildcard query
added ability to run single integration test at a time
added assertion that scoare is not NaN/+Inf/-Inf
New API looks like this:
{"query":{"terms":["watered","down"],"field":"desc"}}
instead of
{"query":{"terms":[{"term":"watered","field":"desc"},{"term":"down","field":"desc"}]}}
So that it eliminats accidental errors by supplying terms with different
fields, or different type of query
This is convenient to see either complicated queries build
programmatically, or to make sure the query parser does what it is
expected to do.
Note only queries made of bleve basic queries are supported. If we
wanted to support external queries, for instance string queries with an
alternative parser, I suggest to introduce some kind of:
type ExpandableQuery interface {
Query
Expand(*IndexMapping) (Query, error)
}
and type assert to that instead of *queryStringQuery.
you can do a manual fuzzy term search using the FuzzyQuery struct
or, more suitable for most users the MatchQuery now supports
some fuzzy options. Here you can specify fuzziness and
prefix_length, to turn the underlying term search into a fuzzy
term search. This has the benefit that analysis is performed
on your input, just like the analyzed field, prior to computing
the fuzzy variants.
closes#82
In the index/store package
introduce KVReader
creates snapshot
all read operations consistent from this snapshot
must close to release
introduce KVWriter
only one writer active
access to all operations
allows for consisten read-modify-write
must close to release
introduce AssociativeMerge operation on batch
allows efficient read-modify-write
for associative operations
used to consolidate updates to the term summary rows
saves 1 set and 1 get op per shared instance of term in field
In the index package
introduced an IndexReader
exposes a consisten snapshot of the index for searching
At top level
All searches now operate on a consisten snapshot of the index
removed analyzers (these are now built as needed through config)
removed html chacter filter (now built as needed through config)
added missing license header
changed constructor signature of filters that cannot return errors
filter constructors that can have errors, now have Must variant which panics
change cdl2 tokenizer into filter (should only see lower-case input)
new top level index api, closes#5
refactored index tests to not rely directly on analyzers
moved query objects to top-level
new top level search api, closes#12
top score collector allows skipping results
index mapping supports _all by default, closes#3 and closes#6
index mapping supports disabled sections, closes#7
new http sub package with reusable http.Handler's, closes#22
Joachim Schwarm