Search only by specific query parameters

[AdamMcAdamson]

To increase the efficiency of our queries, we should only match against indexed fields. If we allow searches by invalid fields (that we cannot create indexes against) it opens us up to reading every document for each empty search. So, we should only allow search by given query parameters.

In general, the documentation outlines what parameters we should be able to query by. For now, keep the query parameter names the same, we can change them down the line.

We should remove the parameters for which indexing is unrealistic/inefficient (i.e. a course's description). (Generally these are never in use) We'll need to update the documentation on the website accordingly.

[TrishT201]

Hey I would like to work on this

[jpahm]

I'm assuming this is open for anyone to do at this point, unless @TrishT201 is still working on this in some capacity.

[TortCode]

I can take this up

[jpahm]

Sounds good, all yours. Let me know if you need any further clarification.

[ahshabbir]

This is something I was thinking we could solve with Filter objects. For example:

type CourseFilter struct {
  SubjectPrefix string
  CourseNumber int
...
}

This way we can type check the parameters. To solve the issue of parsing the queries, we can use the gorilla/schema library. We can then just decode this into a mongodb document and send that as part of the mongodb query. Any thoughts on this?

[jpahm]

I think this is a good idea. Thoughts on this @TortCode?

[TortCode]

I was thinking of implementing something like this manually by annotating certain fields of the models with a "canquery" tag and then making my own encoder/decoder, but I dont want to sloppily reinvent existing functionality. The solution with filters and gorilla/schema looks promising.

[TortCode]

do you an idea on how to handle queries of nested fields (like in professor endpoint) since we need to use dot notation for them

[jpahm]

do you an idea on how to handle queries of nested fields (like in professor endpoint) since we need to use dot notation for them

I wouldn't worry about supporting nested fields -- we probably shouldn't be letting people query by those since we won't be indexing such things. Unless I'm misunderstanding?

[TortCode]

I have the code written. I have not tested it out yet.

[jpahm]

I have the code written. I have not tested it out yet.

Sounds good, thanks!

[jpahm]

@TortCode What's the status on this?

[TortCode]

I need to test this out still

[jpahm]

I need to test this out still

No worries, just keep me updated with any progress or questions👍