Skip to content
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

Categories and Kinds should be handled the same #104

Closed
anselmbradford opened this issue Oct 7, 2013 · 5 comments
Closed

Categories and Kinds should be handled the same #104

anselmbradford opened this issue Oct 7, 2013 · 5 comments

Comments

@anselmbradford
Copy link
Member

The kind and category filters are equivalent kinds of searches, so it seems like they should be handled the same. Currently the kind is an array parameter (kind[]) and the category is a single parameter (category). Having them consistent with each other would simplify client handling of these two types of filters, as the same kind of logic could be used for handling both.

@anselmbradford
Copy link
Member Author

Actually, all filters seem like they should be handled the same, including org_name and language. Would there be any reason not to have all filters of this type be arrays like kind?

@monfresh
Copy link
Member

monfresh commented Oct 8, 2013

Yep, the category and language parameters should be able to support multiple values. I'll update them. org_name, on the other hand, doesn't seem to fit. I don't anticipate people wanting to search for locations that belong to multiple organizations.

@monfresh
Copy link
Member

monfresh commented Oct 8, 2013

I've been trying to get this to work for languages and categories, but haven't had any luck. I'm not quite sure what I'm doing wrong, but it's not a priority, so I'm gonna focus on more important things. If we do revisit this, what would the expected behavior be, that checking multiple languages shows you locations that support ALL those languages, or ANY location that supports ANY of the checked languages?

@anselmbradford
Copy link
Member Author

Hmm, it could go either way I guess, but I think the last scenario, any location that supports any of the checked languages. That would be comparable behavior to the kinds anyway. Supporting all languages would be cool, but perhaps that could be together under one parameter, such as something like:

Results that are spanish or arabic or both:
&language[]=Spanish&language[]=Arabic

Results that are spanish and arabic
&language[]=Spanish,Arabic

@monfresh
Copy link
Member

monfresh commented Sep 9, 2014

This was actually fixed when we implemented Postgres full-text search earlier this year. You can search for multiple categories at once, which will find locations that match either of the categories. For example: https://ohana-api-demo.herokuapp.com/api/search?category[]=Food&category[]=Health

As for support for searching on multiple languages, I just pushed that in #227.

@monfresh monfresh closed this as completed Sep 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants