Specifying Cypher constraints #166
Conversation
Looks good! Some comments... |
I thought the idea was that we were going to specify a syntax for constraints without specifying which particular constraints an implementation should support. The syntax definition here explicitly talks only about |
CIP has now been reworked to try and fit the model discussed. |
* `UNIQUE` - Ensures that each row for a column must have a unique value. | ||
* `PRIMARY KEY` - A combination of a `NOT NULL` and `UNIQUE`. Ensures that a column (or a combination of two or more columns) has a unique identity, reducing the resources required to locate a specific record in a table. | ||
* `FOREIGN KEY` - Ensures the referential integrity of the data in one table matches values in another table. | ||
* `CHECK` - Ensures that the value in a column meets a specific condition |
boggle
Mar 1, 2017
Contributor
Maybe we should have a leading keyword like that for non-UNIQUE constraints as well?
Maybe we should have a leading keyword like that for non-UNIQUE constraints as well?
thobe
Mar 7, 2017
Contributor
if so, I would propose the word THAT
, since it reads nicely...
CREATE CONSTRAINT FOR (x:Foo) REQUIRE THAT ...
if so, I would propose the word THAT
, since it reads nicely...
CREATE CONSTRAINT FOR (x:Foo) REQUIRE THAT ...
4121971
to
22a7f30
On the high level there are two reasons for this:
Diving further into these reasons, starting with the word "primary":
As for the aspects of primary keys in relational databases that do not apply to the property graph model:
The only reason I can think of for introducing the concept of a primary key in Cypher is for being able to map Cypher onto a relational database model. If that is the case I would much rather see this proposed from a vendor working on such a mapping, since they would have the insight into what needs to be modeled. I do think that the notion of a unique indexed key of mandatory properties is helpful, and I see the benefit of elevating such a concept to the status of receiving its own syntax, but I don't think |
==== Mutability | ||
|
||
Once a constraint has been created, it may not be amended. | ||
Should a user wish to change its definition, it has to be dropped and recreated with an updated structure. |
thobe
Mar 7, 2017
Contributor
Should we have a note here that transactional implementations could do both the dropping and recreation in the same transaction so that the constraint is atomically mutated? This would of course allow leaving the old constraint in place should the creation of the new constraint fail.
Should we have a note here that transactional implementations could do both the dropping and recreation in the same transaction so that the constraint is atomically mutated? This would of course allow leaving the old constraint in place should the creation of the new constraint fail.
I wonder if the notion of unique key (that at the moment are erroneously called primary key) should really be a constraint, or if it should have its own syntax, something like:
The reason for this being that it actually implies multiple constraints, and typically also an index. Since it is a composed concept like that, perhaps it would be sensible to elevate it to being a syntactical concept of its own. In the syntax for this, if accepted, we should allow an optional name for the key as well, just like we do for constraints. |
The CIP now uses |
- General outline - Describe the node uniqueness constraint
- Use hex integers for rgb examples
- Specify general constraint language - Specify `UNIQUE` operator - Clearly define semantics for domain and expressions - List all concrete constraints in example section - Add several more examples
They are more appropriate under the Semantics and Syntax sections, respectively.
Move Errors section
References #172
- Remove TODO - Add example using larger pattern - Add example using multiple `exists()`
- Rename `constrait-expr` to `constraint-predicate` - Limit scope of `UNIQUE` to single properties only - Update examples to reflect `PRIMARY KEY`
- Remove erroneous example for composing `NODE KEY` with `UNIQUE` and `exists()` - Rephrase example section to describe `NODE KEY` more accurately.
- Add missing case for when an error should be raised
Add test for DROP
|
It is a little difficult to manage the different comments in the review if they are all in the same message, instead of comments made on/near the lines that triggered them. That would help discussions to be kept disentangled, and suggestions such as the one in item
At this point we discussed this CIP in the CLG, mostly focusing on points |
Specifies syntax for constraints and specifies three concrete constraints: node property uniqueness, node property existence, and relationship property existence.
CIP