sqlalchemy-jsonapi
sqlalchemy-jsonapi copied to clipboard
Query Parameters not implemented?
Hey there,
I'll take a look at serializer again later this week, but from my side it looks like query parameters aren't implemented. From the spec:
Implementation specific query parameters MUST adhere to the same constraints as member names with the additional requirement that they MUST contain at least one non a-z character (U+0061 to U+007A). It is RECOMMENDED that a U+002D HYPHEN-MINUS, “-“, U+005F LOW LINE, “_”, or capital letter is used (e.g. camelCasing).
If a server encounters a query parameter that does not follow the naming conventions above, and the server does not know how to process it as a query parameter from this specification, it MUST return 400 Bad Request.
I'm sending nonsensical query params, and I don't get a 400. Also correctly-formatted QP's don't seem to elicit the right response either.
You are correct that I am not returning a 400. I'll have to fix this.
Ah ok I see the specification leaves QP implementation up to the engineer.
Did you ever get a chance to implement this: https://github.com/ColtonProvias/sqlalchemy-jsonapi/wiki/Filtering
Or Ember-style filters?
I was actually considering making it pluggable. Default to Ember but allow for those other ideas as well.
Does it default to ember-style filtering at the moment?
No filtering at the moment yet. It's on my todo list. With a few of my projects, we're doing all of our filtering client-side temporarily. However, with us getting ready for production, I'm putting focus back into this, so expect filtering soon!
@ColtonProvias, you are truly the man!
Looking at the Ember-style filtering, I found a potential problem. Ember serializes null to an empty-string. Let's assume I want to query for an object where owner is null. Ember would render it as filter[owner]=, which is an empty string. One possible solution would be to specifically state it to be null, but that becomes problematic if null is a valid string.
Thus I'm probably going to have to allow for pluggable filtering. Ship with a basic Ember-compatible filter, but also offer custom filtering and maybe make an adapter for Ember that incorporates it.
I'd say the main use case for this library will indeed be for a "Flyer" stack (Flask-Python-Ember), so Ember-style filters should probably be the default. But pluggability supports the flexibility afforded by the api.
What about a QueryAdapter class that we can sub and inject into FlaskJSONAPI's constructor?
I was thinking about just an overridable function in FlaskJSONAPI for simplicity.
Also, our main use case for this library is providing consistency across mobile platforms with Ember-compatibility being second importance. One of the filtering requirements we have are date ranges, which Ember doesn't exactly handle server-side from what I've seen.
My current plan is to do the following:
?filter[field]=... for ember-style and simple equality filtering with no handling of null.
?filter[field.cmp]=... for a little bit more complexity that can handle null
?filter=urlencoded(cmp) for complex filtering cases.
Ping :) just checking in to see if there's any progress on this.
cough Still wheeze alive... thud
Got a release tomorrow night that is taking priority, but this is still on my todo list!

I fear that release may have been his last...
This is what it's like as I try to get a chance to work on this: https://www.youtube.com/watch?v=GjJCdCXFslY
@ColtonProvias Do you have a POC/WIP branch that we could contribute to/help with/play with? Great thanks!