Add support for bulk-delete

[laurenceisla]

Closes #2314

• Full support for bulk-delete
• Modify error message from 204 to 422 when body is missing/empty
• Tests
• Refactor
• Changelog

---

After much deliberation, the changes implemented are as follows:

• Deletes now allow filters (equality only) in the body. That is:

  DELETE /table
  {"col1": "val1", "col2": "val2"}

  Gives the same result as:

  DELETE /table?col1=eq.val1&col2=eq.val2

• Bulk deletes behave in the same way (body used as filters in the WHERE clause), differentiating themselves from the behaviors with PATCH (body used for values in the SET clause) or POST (body used for values to be inserted).
• Using ?columns circumvent the parsing of the json body, which verifies that all the objects have the same keys, and uses only the specified columns as filters in the query.
• DELETE without filters/body/limits/columns (full table delete) is not allowed and throw an HTTP 422 error.
• If there are filters or limits specified in the query string, then the body will be ignored (for both single object and bulk DELETE).

[steve-chavez]

I think we can close #699 once this is merged(and continue the cancel request part on #2352)

[steve-chavez]

As it is, one deficiency of the new bulk delete(and bulk update suffers from something similar too) is that it doesn't fail with an appropriate message when no filters or body are specified, it just returns 204. This is desirable as discussed on the issues, but it is surprising for someone that hasn't read our docs.

Do you think it would be possible to respond with a 422 when no filters, limits or body are present?

---

For when a body is present, it might be possible to also count the pks in the body on the query and then verify this count is > 0 to fail with the same error(this could be adopted for PATCH too).

[laurenceisla]

I'm not sure about the use of columns in the query string with DELETE. For POST and PATCH it's used as a way to select data from the body to be inserted and updated (in the SET clause). But for DELETE it would be used to select PKs from the body to be used in the WHERE clause, which is redundant since it already filters using the PKs (as seen in this line). I can see these options:

• Do not use columns (but it won't have an option to use the body "as is", without JSON parsing)
• Use it and filter only PKs (will need a warning "Only PKs allowed" if other columns are selected)
• Could be used as a way to add more filters in the body.

[steve-chavez]

Could be used as a way to add more filters in the body.

Hm, this would be useful but it would be inconsistent with bulk PATCH since columns couldn't do the same there.

Use it and filter only PKs (will need a warning "Only PKs allowed" if other columns are selected)

I think this would be the best way for now. Also leaves room for an enhancement later without a breaking change.

[laurenceisla]

After deliberation on another platform, we agreed on using the third option for DELETE:

Could be used as a way to add more filters in the body

Works for single and bulk deletes.

[steve-chavez]

This check would be better at the ApiRequest level since it doesn't depend on the db. This way we avoid taking a pool connection and opening an empty transaction when this error happens.

[steve-chavez]

Hm, I've been thinking that this one could also be done with underscore operators. Like:

DELETE /tbl?id=_in.body->ids

{ "ids": [1,2,3,4]}

I guess one problem with that approach would be how to compare two values that are on the same json object, which this PR already does. For underscore operators, I'm not sure if this would be possible:

DELETE /tbl?col1=_eq.body->*->col1&col2=_eq.body->*->col2


[
  {"col1": "val1", "col2": "val2"}
, {"col1": "val3", "col2": "val4"}
]

The * is borrowed from JSON path's [*] which means get keys from all array elements.

[laurenceisla]

Closed in favor of #2724