Peter Johnson
Peter Johnson
Good point, I was more thinking about trying to prevent bugs by ensuring the tokens were normalized. This normalization needs to be done *both* at index-time and query-time and I...
I found this [old test case](https://github.com/pelias/schema/blob/a3f11067f53e47553f80f765de1a08283acc5c06/integration/source_layer_sourceid_filtering.js#L107) super confusing because it's asserting that the keyword field is case-sensitive even though it should never be the case 🤷♂ [admission of guilt] it...
this config is a useful reference: https://github.com/taskrabbit/elasticsearch-dump/blob/master/.travis.yml
it could be that we are explicitly overriding the default version in our CI config?
Snapshot size comparison:
a bit more info on the code in this PR, the new field is called `concordance` and is an `object` type mapping with string keys (so basically it's the same...
Yeah exactly, so it's set to `keyword` which means there's no analysis (it's just full token exact matching), so no synonyms or anything like that are applied. It's currently set...
a workaround, for now, is to duplicate the token from the left side of the `=>` on the right side as such: ``` hello => hello, world ```
This is only really relevant for custom user-defined synonyms and doesn't affect stock-standard Pelias. So if a user added a synonym `foo => bar` in `custom_name` for instance then all...
One totally valid fix is just to say we don't support the `=>` syntax at all, or that we warn anyone who uses it.