Specify the behaviour of deleted elements#332
Specify the behaviour of deleted elements#332thobe wants to merge 4 commits intoopencypher:masterfrom
Conversation
| These semantics effect the `DELETE` statement itself, even if not succeeded by further read statements, since the same element can occur in multiple rows in the driving table. | ||
|
|
||
|
|
||
| === Accessing properties of deleted Elements |
There was a problem hiding this comment.
This is a change from current behaviour.
This is the main change that people seem to agree that we want from this change proposal.
|
|
||
| Accessing properties of deleted elements produces a `NULL` value, just like accessing a property from a `NULL` value would. | ||
|
|
||
| === Pattern matching on deleted Elements |
There was a problem hiding this comment.
This is a change from current behaviour.
Currently pattern matching on NULL produces 0 rows.
There was a problem hiding this comment.
Why do we deviate from the "behaves like null" in this case?
There was a problem hiding this comment.
The proposal in this section is to have this be the behaviour for all nulls.
|
|
||
| Pattern matching on deleted elements produces a single row containing only `NULL` bindings, in the same way as `OPTIONAL MATCH` would. | ||
|
|
||
| === Deleting deleted Elements |
There was a problem hiding this comment.
This is the same as current behaviour, but should still be documented.
|
|
||
| Deleting a deleted element (or any `NULL` value) is a no-op. | ||
|
|
||
| === Equality of deleted Elements |
There was a problem hiding this comment.
This is a change from current behaviour, where two references to the same element are considered equal even after the element has been deleted.
| RETURN same1, n = m AS same2 | ||
| ---- | ||
|
|
||
| === Deleted elements in paths |
There was a problem hiding this comment.
This is also a change from current behaviour.
The controversial part of it is that it could be argued that it might be expensive to implement such checking to see if the elements of the path have been deleted. I would argue that since all operations on a path accesses all the elements anyhow, the cost of such checking is negligible.
There was a problem hiding this comment.
A nice thing about this behaviour for paths is that it works really well with the (intended) behaviour of UNWIND, where for example UNWIND nodes(p) AS n would produce a single row with n bound to NULL if an element of p was deleted (since p would be considered NULL and nodes(NULL) returns NULL, and UNWIND NULL AS n produces a single row with n bound to NULL).
2 participants
It has become evident that there are some inconsistencies and unhelpful behaviour around the handling of deleted elements. This proposal aims to rectify that.
Aims to specify the semantics requested in #263
CIP2018-10-19