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

Querying for many languages #401

Open
kylemh opened this issue Oct 19, 2020 · 7 comments
Open

Querying for many languages #401

kylemh opened this issue Oct 19, 2020 · 7 comments

Comments

@kylemh
Copy link
Member

kylemh commented Oct 19, 2020

I'm not sure if this is a bug or a feature request, but when querying with both JavaScript and Python, I expected to see results where only both languages were relevant to each and every result. Instead, it was as if I joined the lists of both querying for JUST JavaScript and then JUST Python. I would suggest if a user searches for JavaScript, Python they are met with only resources that contain references to both languages, since they can already query for JavaScript or Python on its own.

@aaron-junot
Copy link
Member

Right, so there was some discussion back and forth about whether it should be the mathematical intersection of both languages, or the union. At some point we decided on the union of both languages, so basically it will return any result that has to do with either language.

I agree that the user can already query for either JavaScript or Python on its own, so you probably want the intersection... I wonder, if we expose a way in the API to specify this, can we make the user choose which they mean if they don't like it?

@aaron-junot
Copy link
Member

Perhaps it would look like a "Show more results" button, and it would show a query for the union of both results rather than the intersection if they didn't end up finding a suitable resource in the initial results.

@kylemh
Copy link
Member Author

kylemh commented Oct 19, 2020

Thanks for the context! I would suggest to do intersection only, and if people request union - we figure it out then!

@Kandeel4411
Copy link
Collaborator

Kandeel4411 commented Oct 20, 2020

Hmm how about we include an additional query param like &join=true or intersect=true or force=true or something else which we could use then to differentiate between if the user wants union or intersection? I think it could help us offer both functionalities if needed and should be backwards compatible too.

@kylemh
Copy link
Member Author

kylemh commented Oct 20, 2020

I'm just not sure how we can convey the difference to the user without being confusing.

@Kandeel4411
Copy link
Collaborator

Kandeel4411 commented Oct 20, 2020

Oh right sorry - I was taking only backend functionality into account. I guess the frontend would need a small additional checkbox that says something like exact [X] or a "Show more results" button as Aaron said if we want both options to be available.

Edit: Nvm - I think intersect only for now might be better and kinda feels more intuitive unless you think the above options wont be confusing

@aaron-junot
Copy link
Member

I think I remember being on the intersect side of the argument when this was decided over a year ago, but I was convinced otherwise by the person I was chatting with. I have no issue changing it to that, I agree it feels the most intuitive.

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

3 participants