4adf4b3dd7
renamed some queries to be quite a bit more informative, however it
wasn't obvious that these query names were used elsewhere in the code.
With those changes, no confidence score middleware was running, which
this should help fix.
The configurable boosts feature can case other unit tests to fail if a
user has customizations in their `pelias.json`.
This adds proxyquire to all tests that might be affected, which force
the default config, preventing such failures.
This adds support for custom boosts to the addressit-style search
queries. The newer libpostal based queries do not include this
functionality since they can only query for addresses.
This is a work in progress to enable customizing boosts for sources and
layers.
For now, the config must be hardcoded in query/autocomplete.js, but it
will eventually be driven by `pelias.json` and take effect on all
endpoints.
Previously, we were conflating environment variable and `pelias.json`
configuration options, and omitted the port option completely.
Add a new section which clearly explains the two environment variables
that affect Pelias API operation.
This adds a structured and detailed log line for each Elasticsearch
query.
It includes information like the total number of Elasticsearch hits, how
long Elasticsearch took to process the request, query parameters, etc.
This is extremely useful for later analysis as the structured nature of
the query allows for powerful filtering.
It's possible for the `text` input to /v1/autocomplete to be of non-zero
length after trimming whitespace and quotes, but still be insufficient
to use for geocoding.
One common case is that it contains only commas, slashes, or other
delimiters.
Our query logic currently does not handle this case, and will generate
Elasticsearch queries that do not have a primary `must` clause and end
up searching every document in the index. These queries are slow, take
up cluster resources, and are not useful.
By detecting unsubstantial inputs, we can prevent this.