-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to dependencies #129
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this change.
The documentation says that the boudary.country
filter accepts an ISO code, so despite the word 'country' being a misnomer I think this filter should support both country and dependency.
As such, the filter is just the opposite of pelias/api#1541
Allowing backwards compatibility is a nice touch, but I'm not too fussed, it should really consider both fields by default.
Hum, ok so instead of retrieving fields using vars and configured in API package, I should add both fields here? |
Good question @orangejulius how do you think we are best to handle this? |
Nice, this is great. Honestly, I think we can keep things simple and add the |
Hum, it seems like search and autocomplete are using a different fields. Search uses While autocomplete uses I don't know if a use |
14d2e20
to
db61e51
Compare
Excellent! I did the update 😉 |
Hi there, I will close this PR given that pelias/api#1622 has already been merged and does the job now. |
I noticed that dependencies were often seen as countries, but it is not possible to use the
boundary.country
parameter to filter searches for documents that are located in dependencies.Now the view
boundary_country
uses amulti_match
query to match bothcountry_a
anddependency_a
.This code is fully backward compatible (needs API changes).