rfcs/mssql-delete-mutations.md
DELETE mutations on SQL Server---
authors: Abby (@sassela), Gil (@soupi)
---
As a user, I would like to be able to delete rows from a certain mssql table using a predicate, similarly to how I'm able to do so for a postgres table.
Deleting rows from a table should be done via sending a GraphQL mutation to the /v1/graphql endpoint.
Delete mutations should respect row-level permissions.
Users can specify a deletion mutation in one of the following ways:
delete syntax
Delete via a predicate on one of the root table fields:
https://hasura.io/docs/latest/graphql/core/api-reference/graphql-api/mutation.html#delete-syntax
Delete via a predicate on one of the nested object fields:
Delete all objects in a table using the {} expression as the where argument:
delete syntax:
mutation [<mutation-name>] {
<mutation-field-name> (
[where-argument!]
) {
[mutation-response!]
}
}
delete_by_pk syntax:
The mutation response is specified in the GraphQL spec, including:
{ data # the returned data is specified by the `mutation-response` section
{
affected_rows
returning { # the `returning` statement can include nested objects
response-field1
response-field2
..
}
}
}
or ...
{ errors {
extensions
message
}
}
TestGraphqlDeleteBasicTestGraphqlDeletePermissionsTestGraphqlDeleteConstraintsTestGraphqlMutationCustomGraphQLTableNameTestGraphqlMutationCustomSchemaThese checkpoints do not necessarily need to be delivered in the same PR. In fact, prefer smaller PRs where they are functional, tested, and self-contained.
DELETE mutations schema by completing the msBuildTableDeleteMutationFields functionDELETE SQL by adding an executeDelete function
convertDelete can be used as a reference implementation for SQL generation
executeInsert can be used as a reference implementation for mutation response generation
We cannot retrieve returning fields once the delete statement is executed.Consider the following options to fetch returning output:
OUTPUT clause to capture the delete statement's output.SELECT then DELETE: Fetch the data for returning and affected_rows fields first, by running the SELECT query generated by mkMutationOutputSelect inclusive of the DELETE query's WHERE and permissions filters, i.e.
WITH with_alias AS (
SELECT * FROM table_name WHERE <where-from-delete-query>
)
<select statement generated by mkMutationOutputSelect function>
DELETE statementDevelopers should consider the possible interaction with transaction isolation levels of both approaches when implementing. Whilst the first option is recommended after some internal discussion, developers should revive the discussion with @hasura/server-data-sources or do a short technical spike if there is any uncertainty about the better approach.
Nested return statements can be supported by drawing inspiration from the existing mkMutationOutputSelect function.
Delete permissions are bundled in the IR with the WHERE expression, in mkDeleteObject; the generated SQL should contain the filter expression and permissions in the same WHERE clause.
Regarding INSTEAD OF DELETE triggers: we need not try and do anything better than the limitations of the OUTPUT statement.