Relax inffecient query validation for deployments api
What does this MR do and why?
We were planning to deprecate usage of order=updated_at
and updated_before/afted=
without each other in the deployments API(you can still use them if you combine these 2 options). Mainly because users can create not very efficient queries like: updated_before=something&order=id
, and we don't have index to facilitate this query.
While investigating [existing usage do deployments API]#328500 (comment 1360432298)), I realized that some users are using completely legit query order=updated_at&sort=desc
which is basically "give me deployments sorted by the time they were updating".
If we just implemented [Breaking Change] Returns an error when `update... (#328500 - closed) as is, e.g. in Draft: Remove deployments_raise_updated_at_inef... (!116658 - closed), we would:
- affect a lot of users workflows
- force them add a workaround like "updated_after=1970..." which won't make the query more efficient.
So this MR relaxes the inefficient query validation: now if you use updated_before/after
you need to also specify sorting, but you can use order=updated_at
without these filters...
This should minimize impact on existing user workflows while still allowing us to deprecate unreasonable and performance affecting queries like updated_before=something&order=id
.
Once this is in production, I'll reevaluate the impact, and adjust the Draft: Remove deployments_raise_updated_at_inef... (!116658 - closed)
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.