Closed qasim closed 8 years ago
I think there's also the advantage that it can be used without any parameters. Say I was interested to see all courses that have something to do with "software engineering". I could use /search?q="software engineering"
, rather than /filter?q=name="software engineering" OR description="software engineering"
.
I guess the argument could go both ways here, since the only downside of using /filter
is length... 😕
Maybe discontinuing /search
and just focusing on improving string filtering is the better idea. Do you think it's possible to add an all_strings
key (possibly all_numbers
, etc.) for querying all string types? That way we can bring /search
functionality to /filter
.
Hm... you're right about the convenience of being able to do a generic search without any parameters, that is pretty attractive. I guess we can hold back on this for now. The all_strings
/ all_numbers
solution doesn't seem so elegant.
The only thing that I don't like about search is that it doesn't allow for partial word searching, since that's the nature of a full text search. You'll get results for computer science
but maybe not so many for CSC
, only those that literally have the word CSC
in the description. I guess we can just focus on improving /search
algorithm to allow for partial word searches (we'll lose the ability to search on the pre-computed indexes, but that's fine).
Search functionality can be reproduced in filter by doing string comparisons. Search's only advantage is that it can do whole word text searches on pre-computed indexes (some speed increase). But it does add a little bit of confusion for a new user to figure out if that's even worth it. Should we just discontinue search and improve our algorithm for filter string comparisons?