-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prefer: handling=strict; affected
for conditional requests based on number of affected resources
#2887
Comments
If-Affected
header for conditional requests based on number of affected resourcesPrefer: handling=strict; affected
for conditional requests based on number of affected resources
I've repurposed this proposal to use the newly added Edit: I don't see any problem this could introduce as it's namespaced and optional, so will mark it as enhancement. |
Hmm, doesn't |
@taimoorzaeem Right. My mistake, corrected the above. |
@steve-chavez Prefer: return=representation, handling=strict, affected=gt.1,lte.10 Internally, splitting it comma would yield ["return=representation", "handling=strict", "affected=gt.1", "lte.10"] This split the affected preferences into two. Should we change the delimiter to |
@taimoorzaeem Right,
Perhaps easier to parse too? WDYT? |
@steve-chavez I think that using the I think it would be better to implement this with a custom header like |
@taimoorzaeem I see, it makes sense that putting syntax in
Yes, agree. |
@taimoorzaeem I've been thinking more about this. Now that we have Really the use case is to limit the amount of rows affected, that much flexibility with operators is not really necessary. So: Accept: application/vnd.pgrst.array?max-length=100 WDYT? Should be easier to implement too. Caveat: this would only be tied to JSON, but that's the immediate use case. |
Actualy it might be even easier to do:
That would not be tied to JSON. |
Problem
Currently checking the number of affected resources for a request is tied to the
application/vnd.pgrst.object+json
media type and it only checks for a value of 1.Solution
Now that we have
Prefer: handling=strict
, we can err on unmet conditions. This gives us an equivalent of theExpect
header and can be used independently of the media type and request method.We can have an
affected
preference, which would be a count of the operation affected resources. Its syntax would be:Assuming
items
has 1000 items:Correcting the request with a filter:
If
handling=lenient
is used or ifhandling=strict
is not specified,affected=..
won't have any effect.Notes
HAVING clause
as mentioned here.Prefer
header: Conditional delete/update based on rows affected #2156The text was updated successfully, but these errors were encountered: