Specifying Cypher constraints

[Mats-SX]

Specifies syntax for constraints and specifies three concrete constraints: node property uniqueness, node property existence, and relationship property existence.

CIP

[petraselmer]

Looks good! Some comments...

[petraselmer]

"utility for shaping the data graph" -> "the means by which various facets of the data graph may be controlled"

[petraselmer]

"of schema" -> "of a schema"

[petraselmer]

"Constraints allows us to bound" -> "Constraints allow us to bind"

[petraselmer]

"its own below section" -> "its own section below"

[petraselmer]

Please quote / emphasize "foo" in some way

[petraselmer]

"Ensure the referential integrity of the data in one table to match values in another table"
->
"Ensures the referential integrity of the data in one table matches values in another table"

[petraselmer]

Format 'persons'

[petraselmer]

Format 'persons'

[petraselmer]

"keep graphs in a more regular, easier to manage form."
->
"maintain graphs in a more regular, easier-to-manage form."

[petraselmer]

"For an implementing system"
->
"For a system seeking to implement the contents of this CIP"

[petraselmer]

"look for" -> "locate"

[thobe]

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 uniqueness-constraint and existence-constraint.

[Mats-SX]

CIP has now been reworked to try and fit the model discussed.

[boggle]

Couldn't this just be any pattern, same way as we allow in MATCH? Implementations would still be free to support only some forms in their constraints.

[boggle]

Or even a comma-separated sequence?

[Mats-SX]

You're right, I don't see why not.

[boggle]

I think the correct thing here is to align with Cypher identifier syntax for now.

[boggle]

We should also support escaping of names.

[Mats-SX]

Escaping is captured by referring to the symbolicString rule.

[boggle]

I'm missing an example for an existence constraint that requires multiple properties to exist on a node; this can be expressed using exists(n.foo) AND exists(n.bar).

[Mats-SX]

Right, or using multiple REQUIRE. I can add both.

[boggle]

Maybe we should have a leading keyword like that for non-UNIQUE constraints as well?

[thobe]

if so, I would propose the word THAT, since it reads nicely...

CREATE CONSTRAINT FOR (x:Foo) REQUIRE THAT ...

[IanRogers]

typo? uniqune -> unique

[Mats-SX]

Thanks!

[IanRogers]

Sorry, this isn't what #173 is talking about. The "unique" constraint on a DAG would be require size(p) < 2 though this is a generalisation of require unique p (i.e. to enforce the behaviour of create unique http://neo4j.com/docs/developer-manual/current/cypher/clauses/create-unique/#_create_unique_relationships)

[Mats-SX]

You're right; length() actually doesn't make much sense here (it will always be 1 with this pattern). Although size() doesn't either, as it's not defined over paths at all.

Perhaps

REQUIRE size(collect(DISTINCT p)) < 2

would work, but it's not very pretty. We probably need some other construct here. I'll remove this example for now.

[thobe]

PRIMARY KEY is not a helpful name for the concept it is used for describing.

On the high level there are two reasons for this:

1. The word "primary" does not mean anything that is helpful in this context.
2. The concept of primary keys carries with it a lot of associations from relational databases, many of which do not apply to the property graph model.
   • it should be noted that for the relational database case the word "primary" does have relevant meaning.

Diving further into these reasons, starting with the word "primary":

• It implies that there is such a thing as a "secondary" key as well. In a relational database a secondary key is any index on a table other than the primary key.
• It implies that this key has higher importance than any other key. While this might be true in many actual domain models, it is not always the case - in some cases there are other keys of equal importance.
• It carries with it the association that there can be only one primary key. In many implementations - Neo4j being one of them - there is absolutely no need to enforce such a constraint on the ability to model your data.
• It implies that the key needs to be defined first - before any data is inserted. In many implementation - Neo4j being one of them - this is not the case.

As for the aspects of primary keys in relational databases that do not apply to the property graph model:

• The notion of there being a primary key implies that there might also be a foreign key - the idea of having foreign keys in a graph is quite silly, since we have direct relationships.
• Coming from relational databases, I would expect preferential treatment for primary keys over any other (secondary) keys. I would expect lookup based on the primary key to be faster than any other key, since I would expect the data in that table to be structured by the primary key. In essence I would expect that leaf nodes in the index for the primary key being the actual row, with all of its data. Whereas for a secondary key the leaf node would only point to the actual row in the primary structure - there would be indirection for accessing the full data by a secondary key, thus penalizing access by secondary key.
  • Again this would not be true in for example Neo4j, where every key is actually secondary.
• Relational databases equate the primary key with identity, the property graph (at least in some implementations - for example Neo4j) has a separate notion of identity, and while the type of key we are proposing to add to the model would allow you to uniquely identify an entity, it would not necessarily identify that same entity forever - the same entity might change some of the values of the key and thus be identified by a different key, but still have the same identity.

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 PRIMARY KEY is a good name for it.

[thobe]

This decomposition seems wrong to me, we would want the compound key to require that the combination of p.name, p.email, and p.address is unique, not that each of them is unique on their own. But we do require that they each exist.

[Mats-SX]

Right, without UNIQUE on multiple properties, this is not expressible in another way.

[thobe]

I know there has been conversation about how CREATE is an overloaded word if used for constraints as well, since it is already used for creating nodes and edges. I just wanted to plant the idea of using the word DEFINE for constraints instead. i.e. DEFINE CONSTRAINT FOR (p:Person) REQUIRE UNIQUE p.firstName, p.lastName

[thobe]

I think we want this to be a list of expressions in order to allow compound keys to be unique.

[Mats-SX]

I view that as out of scope for the first version of this CIP.

[thobe]

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.

[thobe]

+ attempting to create a constraint that the underlying engine does not support enforcing.

[thobe]

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:

CREATE KEY FOR (p:Person) AS p.name, p.address

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.

[Mats-SX]

The CIP now uses ADD, NODE KEY and details a return record. I also took several review comments into account (thanks!).