Query Parameters not implemented?

[Datamance]

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.

[ColtonProvias]

You are correct that I am not returning a 400. I'll have to fix this.

[Datamance]

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?

[ColtonProvias]

I was actually considering making it pluggable. Default to Ember but allow for those other ideas as well.

[Datamance]

Does it default to ember-style filtering at the moment?

[ColtonProvias]

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!

[Datamance]

@ColtonProvias, you are truly the man!

[ColtonProvias]

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.

[Datamance]

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?

[ColtonProvias]

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.

[Datamance]

Ping :) just checking in to see if there's any progress on this.

[ColtonProvias]

cough Still wheeze alive... thud

Got a release tomorrow night that is taking priority, but this is still on my todo list!

[Datamance]

I fear that release may have been his last...

[ColtonProvias]

This is what it's like as I try to get a chance to work on this: https://www.youtube.com/watch?v=GjJCdCXFslY

[guillett]

@ColtonProvias Do you have a POC/WIP branch that we could contribute to/help with/play with?
Great thanks!