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.
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.
This is a somewhat roundabout fix to #1179,
as a way to deal with the persistent npm ls
and commit hook troubles we were dealing with
due to dependencies of the iso3166 package.
Additionally it should give us a faster
definition of these ISO lookups, since the
existing approaches were implemented using
linear scans through an array rather than
map-based lookups.
`/place` queries have been executing in a way where only the ID, but not
the layer, has been considered when returning records from
Elasticsearch.
It turns out this bug was introduced almost a year and a half ago in
https://github.com/pelias/api/pull/407. A little, relatively unimportant
bit of code was looking for a property called `layers`:
```
const cmd = req.clean.ids.map( function(id) {
return {
_index: apiConfig.indexName,
_type: id.layers,
_id: id.id
};
});
```
The correct property was `layer`, so no filtering on layer was done in
the resulting [mget](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html) query.
There was never an acceptance test for these sorts of queries, but there
is now one in https://github.com/pelias/acceptance-tests/pull/446. The
unit tests were enforcing the incorrect behavior.
Fixes https://github.com/pelias/pelias/issues/643