Deleting by changing

What this is about

DELETE is not the only thing that deletes. A PUT or PATCH on the parent can delete children too, namely when a dependent child (relation with the DELETE flag) no longer belongs to it afterwards. This happens when

• a list is sent without the child,
• a list counts as empty,
• a single reference is cleared.

This is intended: an invoice item that drops out of its invoice makes no sense without the invoice. But it is also the most common way to delete data by accident.

Before and after

A contact with a main phone mainPhone and further phones phones. Both relations have the DELETE flag.

The last two rows are the difference between PUT and PATCH: with PUT, “missing” means the same as “empty”; with PATCH, “missing” means “do not touch”.

PATCH /api/rest/crm/contact/update/c052…
{
  "data": {
    "id": "c052…",
    "phones": [ { "id": "P2…" } ]
  },
  "response": ["id", { "field": "phones", "response": ["id", "number"] }]
}

{ "data": { "id": "c052…",
            "phones": [ { "id": "P2…", "number": "0611-17277000" } ] },
  "meta": { "error": false } }

Afterwards P3 has not only disappeared from the list, it is deleted. /phone/read/P3… returns 404.

When a child is deleted

“Contained” means: the child is in the list or the reference with its id. Which other fields you send along makes no difference for this. See Lists as target state.

What happens

Everything from Dependent objects (cascades) applies to the deleted child: it needs the delete role of its model, its own dependent children go along, its other relations are unlinked.

Pitfalls

What comes next

• The rules for lists: Lists as target state
• PUT and PATCH compared: PUT or PATCH? The null trap
• What is deleted along: Dependent objects (cascades)