querying for subject

[mystor]

There is currently no way to query the api such that it returns all courses within a specific subject, this is because the link property for the subject is contained within a dictionary, thus the dumb query cannot see it.

This means that the front end considers every course to be in every subject. For some reason I feel like that could cause problems.

[uniphil]

Yeah that needs to be either mapped, or maybe we should return something flat instead of an object on the API?

[mystor]

I think that our mapping function in the apis should recognize links and allow requests by them. I don't think we need to or should flatten them. I think we should try to return the same type of object as it will be, except with fewer properties.

[Graham42]

I think that all objects should have a unique identifier and then allow queries to filter by a nested object's UID.

Example: The course CMPE 324 has a property subject which is a nested object. The subject has a uid property with the value "CMPE". The purpose of this would be so a query of /courses/?subject=CMPE would return all courses with the subject "CMPE"

The same idea could apply to courses by instructor(s) or any other nested object

[mystor]

Objects do have a unique ID right now. At the moment, the unique identifier is called 'link'.

The unique identifier right now is not intended to be directly related to the code of the course, so the frontend is doing a subject lookup followed by a course lookup.

I believe that the query should look as follows under the current system: /courses/?subject=/subjects/CMPE where /subjects/CMPE is the link to CMPE.

On Mon, Jan 13, 2014 at 12:56 PM, Graham42 notifications@github.com wrote:

I think that all objects should have a unique identifier and then allow queries to filter by a nested object's UID.

Example: The course CMPE 324 has a property subject which is a nested object. The subject has a uid property with the value "CMPE". The purpose of this would be so a query of /courses/?subject=CMPE would return all courses with the subject "CMPE"

The same idea could apply to courses by instructor(s) or any other nested object

— Reply to this email directly or view it on GitHubhttps://github.com/Queens-Hacks/qcumber-api/issues/20#issuecomment-32193430 .

[Graham42]

So the link is really two parts, a type and a unique identifier {type}/{uid}. So yes the link is a unique property of the object, but it's not really an "id". What i'm suggesting is a property separate from the link.

The query you suggest does not seem like a clean solution at all.

[mystor]

I agree that it doesn't look clean, but it does make sense, to an extent, as that is what is stored in the model. I fully support the API implementing a cleaner frontend which uses uids, as long as it doesn't require me to jump through hoops when writing the frontend (I think that doing that generally means that the API is flawed).

On 1/13/14, Graham42 notifications@github.com wrote:

So the link is really two parts, a type and a unique identifier {type}/{uid}. So yes the link is a unique property of the object, but it's not really an "id". What i'm suggesting is a property separate from the link.

The query you suggest does not seem like a clean solution at all.

---

Reply to this email directly or view it on GitHub: https://github.com/Queens-Hacks/qcumber-api/issues/20#issuecomment-32214108

[pR0Ps]

When filtering on subjects, can we not just assume that the parameter is going to be a subject?

That way, when entering: /courses/?subject=CMPE, the API could add the 'type' to the parameter, giving courses/?subject=/subjects/CMPE, which is the unique ID of the subject.

In the same way, /terms/?course=CMPE-101 would become the equivalent of /terms/?course=/courses/CMPE-101