Future features for openCypher: Schema, Constraints, Subqueries, Configurable Pattern Matching, Conjunctive regular Path Queries

opencypher.orgopencypher.org | opencypher@googlegroups.com
Schema and Constraints
Mats Rydberg
mats@neotechnology.com

● Cypher is schema-optional
● Fits well with heterogenous data
● Makes typing and query planning harder
● Does not fit well with many existing table-based engines
● Constraints are the only tools to enforce structure in the data
Schema in Cypher is a point where we expect there to be major
developments as more actors get involved.
Schema in Cypher
2

● Consistent syntax for all types of constraints (CIP)
● Re-use as much as possible from the rest of the language
● Allow for a large set of future constraints, some of which are
vendor-specific
● This allows vendors to use more strict schema when necessary
CREATE CONSTRAINT <name>
FOR <simple pattern>
REQUIRE <constraint expression>
New constraint syntax
3

● Property uniqueness constraint
➢ CREATE CONSTRAINT unique_person_names
FOR (p:Person)
REQUIRE UNIQUE p.firstName, p.lastName
● Property existence constraint
➢ CREATE CONSTRAINT person_must_have_firstName
FOR (p:Person)
REQUIRE exists(p.firstName)
Constraints, examples
4

● Property value constraint
➢ CREATE CONSTRAINT roads_must_have_positive_finite_length
FOR ()-[r:ROAD]-()
REQUIRE 0 < r.distance < infinity
● Property type constraint
➢ CREATE CONSTRAINT people_schema
FOR (p:Person)
REQUIRE p.email IS STRING
REQUIRE p.name IS STRING?
REQUIRE p.age IS INTEGER?
5

● Cardinality constraints
➢ CREATE CONSTRAINT spread_the_love
FOR (p:Person)
REQUIRE size((p)-[:LOVES]->()) > 3
● Endpoint constraints
➢ CREATE CONSTRAINT can_only_own_things
FOR ()-[:OWNS]->(t)
REQUIRE (t:Vehicle) OR (t:Building) OR (t:Object)
● Label coexistence constraints
➢ CREATE CONSTRAINT programmers_are_people_too
FOR (p:Programmer)
REQUIRE p:Person
6

That's it!
Questions ?

Subqueries
Petra Selmer
petra.selmer@neotechnology.com

MATCH (actor:Actor)
WHERE EXISTS {
(actor)-[:ACTED_IN]->(movie),
(other:Actor)-[:ACTED_IN]->(movie)
WHERE other.name = actor.name
AND actor <> other
}
RETURN actor
Existential subqueries
CIP
9

MATCH (f:Farm {id: $farmId})-[:IS_IN]->(country:Country)
MATCH {
MATCH (u:User {id: $userId})-[:LIKES]->(b:Brand)
RETURN b AS item, b.designedDate AS dateOfInterest
UNION
MATCH (u:User {id: $userId})-[:BOUGHT]->(v:Vehicle)
WHERE v.leftHandDrive = country.leftHandDrive
RETURN v AS item, v.manufacturedDate AS dateOfInterest
}
RETURN DISTINCT v.code
ORDER BY dateOfInterest
Nested correlated subqueries
CIP
10

MATCH (r:Root)
DO {
UNWIND range(1, 10) AS x
MERGE (c:Child {id: x})
MERGE (r)-[:PARENT]->(c)
}
● UNWIND manages the looping
● DO suppresses the increased cardinality from the inner query
● DO hides all new variable bindings (e.g. c)
Nested read/write subqueries
CIP
11

MATCH (actor:Actor)
WHERE actor.age > {
MATCH (director:Director)-[:DIRECTED]->(:Movie)
RETURN max(director.age)
}
RETURN actor.name, actor.details
Scalar subqueries
12
CIR

Homomorphic and Isomorphic
Pattern Matching
Stefan Plantikow
stefan.plantikow@neotechnology.com

• MATCH(a)-[r]->(b)
≡ { (a, r, b) V E V | r (a,b) }
• MATCH (a)-[r1]->(b)-[r2]->(c)
≡ { (a, r1
, b, r2
, c) V E V E V | r 1
(a,b) r 2
(b,c) r1
≠ r2
}
• MATCH (a)-[rs*]->(b)
≡ { (a, rs, b) V E*
V | rs *
(a,b) rs=[...,r1
...,r2
,...] r1
≠ r2
}
Basic Pattern Matching Semantics
15

• Why?
• No uniqueness Potentially infinitely many matching paths
• Node uniqueness Can't match self-loops
• When?
• All pattern variables in a MATCH
• And similar constructs (comprehensions etc.)
• Optional?
• Not for variable length
Default Uniqueness = Relationship Uniqueness
16

• CIR 2017-174
• Defines uniqueness scope precisely
• Add configurable uniqueness
• No uniqueness => Graph homomorphism
• Relationship uniqueness => Graph (relationship) isomorphism
• Node uniqueness => Graph (node) isomorphism
• Default uniqueness
• Cardinality & path matching semantics
Let's fix this: Requirements
17

• CIP 2017-01-18
• Uniqueness mode specifiers
• MATCH ALL (a)-[r*]->(b)
• MATCH UNIQUE RELATIONSHIPS
• MATCH UNIQUE NODES
• Subquery uniqueness mode specifiers
• MATCH [MODE] { ... }
• DO [MODE] { ... }
Let's fix this: Proposal
18

• CIP 2017-01-18: Path predicates
• MATCH ALL p=()-[:T1*]->()<-[r:T2]->() WHERE ...
• node-isomorphic nodeUnique(p)
• relationship-isomorphic relUnique(p)
• has cycles | has no cycles open(p)|closed(p)
• no immediately repeated rels trek(p)
• no repeated cycles NOT redundant(p)
• ...
Let's fix this: Proposal
19

(Conjunctive) Regular Path Queries
“Regular expressions over Graphs”
Tobias Lindaaker
tobias@neotechnology.com

We’ve been wanting to do this for long
Been trying to find well balanced syntax
22

Regular Path Patterns
• Disjunctions (unions) between patterns:
(a)-/alt1 | alt2 | alt3/-(b)
• Sequence of patterns:
(a)-/first second third/->(b)
• Repetition of pattern:
(a)<-/(many times)*/-(b)
• Definition of complex pattern predicates:
MATCH (a)-/complex/->(b)
PATH (x)-/complex/->(y) IS
(x)-[:LOVES]->(y), (y)-[:HATES]->(x)
• Shorthand for simple predicates:
(a)-/:REGULAR_RELATIONSHIP_TYPE/->(b)
• Combinations of the above
23
(CIP2017-02-06)

Origins of the syntax in CIP2017-02-06
“Canterbury Style”
(from a meeting in Canterbury, summer 2015)
● In-line pattern expression
MATCH p=(a:Person{a})[
(x)-[:AUTHORED]->(:Book)<-[:AUTHORED]-(y)
WHERE x <> y
]*(b:Person{b})
RETURN p ORDER BY length(p) ASC LIMIT 1
Pros
● Pattern visible where used
Cons
● Large patterns, hard to overview
24
“PGQL Style”
(inspired by the path patterns in PGQL)
● Composition of simple pattern declarations
PATH CO_AUTHORED :=
(x)-[:AUTHORED]->(:Book)<-[:AUTHORED]-(y)
WHERE x <> y
MATCH p=(a:Person{a})-/CO_AUTHORED*/-(b:Person{b})
RETURN p ORDER BY length(p) ASC LIMIT 1
Pros
● No nested syntax, each pattern is clear
● Allows reuse of complex sub-pattern
● Pattern definitions align with “path-views”
Cons
● Definition removed from use
● Everything needs to be declared to be used
● Unclear which nodes are input, and which are
internal to a PATH pattern

Syntax tradeoffs
Desirable
• Pattern visible where used
• No unnecessary ceremony
• Transparent complexity
• Familiar regular language
• Allow reuse of complex
sub-patterns
Undesirable
• Lots of details in patterns
- hard to view structure
• Definition of pattern
removed from use
• Very many ways to express
the same thing
25

Evolving from Cypher today
• Limited support today:
• Disjunction on edge label: ()-[:A|B|C]->()
• Repetition of single edge: ()-[:X*]->()
• unhelpful when binding: ()-[x:X*]->() - binds as list!
• (these two forms can be combined)
• Regular Path Patterns
replace existing repetition syntax
• For CRPQs (Conjunctive Regular Path Queries)
Cypher need only add Regular Path Patterns,
it already has conjunctions
26

Expressive powerComparing to GXPath (path expressions)
• ⟦ε⟧G
- {(v,v) | v ∈ V} - yes: PATH (a)-/nop/-(a) IS (a)
• ⟦_⟧G
- {(v,w)| (v,a,w) ∈ E for some a}
- yes: PATH (a)-/any/->(b) IS (a)-->(b)
• ⟦a⟧G
- {(v,w)| (v,a,w) ∈ E} - yes: (v)-/:a/->(w)
• ⟦a-
⟧G
= {(v,w) | (w,a,v) ∈ E} - yes: (v)-/<:a/->(w)
• ⟦ɑ*⟧G
= reflexive transitive closure of ɑ
- yes: ()-/ɑ*/->()
• ⟦ɑ · β⟧G
= ⟦ɑ⟧G
⟦β⟧G
- yes: ()-/ɑ β/->()
• ⟦ɑ ∪ β⟧G
= ⟦ɑ⟧G
∪ ⟦β⟧G
- yes: ()-/ɑ|β/->()
• ⟦¬ɑ⟧G
= V V - ⟦ɑ⟧G
- maybe:
PATH (v)-/not_alpha/->(w) IS (v), (w)
WHERE NOT EXISTS { (v)-/ɑ/->(w) }
Warning: the above is intractable, we might want to restrict to connected patterns
• ⟦[φ]⟧G
= {(v,v) | v ∈ ⟦φ⟧G
}
- yes: PATH (v)-/phi/-(v) IS (v) WHERE φ
• ⟦ɑn,m
⟧G
= ⋃k=n
m
(⟦ɑ⟧G
)k - yes: ()-/ɑ*n..m/->()
• ⟦ɑ=
⟧G
= {(v,w) ∈ ⟦ɑ=
⟧G
| ρ(v)=ρ(w)}
- yes: PATH (v)-/alpha_eq/->(w) IS (v)-/ɑ/->(w) WHERE v.ρ = w.ρ
• ⟦ɑ≠
⟧G
= {(v,w) ∈ ⟦ɑ=
⟧G
| ρ(v)≠ρ(w)}
- yes: PATH (v)-/alpha_not_eq/->(w) IS (v)-/ɑ/->(w) WHERE v.ρ <> w.ρ
• Conjunctions (for CRPQs): ⟦ɑ ∩ β⟧G
= ⟦ɑ⟧G
∪ ⟦β⟧G
- yes: PATH (v)-/alpha_and_beta/->(w) IS (v)-/ɑ/->(w), (v)-/β/->(w)
2
7
27Querying Graphs with Data - L.Libkin, W.Martens, D.Vrgoč

Expressive power
Comparing to GXPath (node tests)
• ⟦⟨ɑ⟩⟧G
= {v | ∃w (v,w) ∈ ⟦ɑ⟧G
}
- yes: PATH (v)-/has_alpha/-(v) IS (v)-/ɑ/->()
• ⟦¬φ⟧G
= V - ⟦φ⟧G
- yes: PATH (v)-/not_phi/-(v) IS (v) WHERE NOT φ
• ⟦φ ∧ ψ⟧G
= ⟦φ⟧G
∩ ⟦ψ⟧G
- yes: PATH (v)-/phi_and_psi/-(v) IS (v) WHERE φ AND ψ
• ⟦φ ∨ ψ⟧G
= ⟦φ⟧G
∪ ⟦ψ⟧G
- yes: PATH (v)-/phi_or_psi/-(v) IS (v) WHERE φ OR ψ
• ⟦c=
⟧G
= {v ∈ V | ρ(v) = c}
- yes: PATH (v)-/rho_is_c/-(v) IS (v) WHERE v.ρ = c
• ⟦c≠
⟧G
= {v ∈ V | ρ(v) ≠ c}
- yes: PATH (v)-/rho_is_c/-(v) IS (v) WHERE v.ρ <> c
• ⟦⟨ɑ = β⟩⟧G
= {v ∈ V | ∃w,y (v,w)∈⟦ɑ⟧G
, (v,y)∈⟦β⟧G
, ρ(w)=ρ(y)}
- yes: PATH (v)-/alpha_eq_beta/-(v) IS
(v)-/ɑ/->(w), (v)-/β/->(y) WHERE w.ρ = y.ρ
• ⟦⟨ɑ ≠ β⟩⟧G
= {v ∈ V | ∃w,y (v,w)∈⟦ɑ⟧G
, (v,y)∈⟦β⟧G
, ρ(w)≠ρ(y)}
- yes: PATH (v)-/alpha_not_eq_beta/-(v) IS
(v)-/ɑ/->(w), (v)-/β/->(y) WHERE w.ρ <> y.ρ
2
8
28Querying Graphs with Data - L.Libkin, W.Martens, D.Vrgoč

Can we do even better?
• Shorthand syntax for node labels
• Shorthand syntax for matching any edge
• Shorthand syntax for property predicates
• What is the scope of PATH declarations?
• ...and where in the query should they go?
• Beginning of query?
• Sub-clause of MATCH?
• Anywhere in the query?
• Can we parameterize PATH declarations?
• ...and use parameters for both input and output...
2
9
29

<Your suggestion here>
What other features would
you like to see in Cypher?

Future features for openCypher: Schema, Constraints, Subqueries, Configurable Pattern Matching, Conjunctive regular Path Queries

More Related Content

What's hot (20)

Similar to Future features for openCypher: Schema, Constraints, Subqueries, Configurable Pattern Matching, Conjunctive regular Path Queries (20)

More from openCypher (20)

Recently uploaded (20)

Future features for openCypher: Schema, Constraints, Subqueries, Configurable Pattern Matching, Conjunctive regular Path Queries