Cypher is a high-level query language for the property graph data model. Cypher is similar to SQL in many aspects. Some of its main differences are:
- Instead of SQL's SELECT/FROM/WHERE, Cypher has MATCH (equivalent to FROM) WHERE, and RETURN (equivalent to SELECT) as its main query clauses.
- Instead of SQL's INSERT/UPDATE/DELETE, Cypher has CREATE/SET/REMOVE data manipulation clauses.
- Joins between the records of different (node/rel) tables are specified using a graph-syntax.
- There are special syntax, such as the Kleene star, or min...max, to describe variable-length and recursive joins. There are other differences between SQL and Cypher. Yet, similar to other high-level database query languages, it is very much like SQL and most of its semantics can be understood as mappings to relational algebra operations of selections, joins, projections, or group-by and aggregations.
Kùzu's query language is based on the openCypher variant of the Cypher query language. In this part of the documentation, we cover those clauses that are implemented in Kùzu.
🗃️ Data Types
🗃️ Functions and Expressions
🗃️ Data Manipulation
🗃️ Query Clauses
COPY statement moves data between external files and database internal.
Subquery in Kùzu can only be a single MATCH clause optionally followed by a WHERE clause. No other clauses is allowed.
📄️ Database Configuration
The configuration of Kùzu can be changed through standalone Call statement. Different from the Call clause, this statement of changing configuration cannot be used with other query clauses.
Kùzu allows user to create a macro in catalog using the create macro statement. The process of creating macros involves using the CREATE MACRO keyword followed by the macro's name. Users can optionally include parameters with optional default value within parentheses after the name. The "AS" keyword comes next, followed by the actual cypher expression of the macro. It's important to note that a scalar macro is limited to returning only a single value.
Kùzu is a transactional system. Specifically, it implements a transaction management sub-system that is atomic, durable and supports serializability (satisfying these properties is traditionally known as being ACID-compliant in database terminology). That is, every query, data manipulation command, every DDL (i.e., new node/rel table schema definitions), or COPY FROM commands to Kùzu is part of a transaction. Therefore they depict all-or-nothing behavior, so after these commands or a set of them execute and committed successfully, you are guaranteed that all of their changes will persist entirely. If they do not execute successfully or are rolled back, you are guaranteed that none of their changes will persist. These conditions hold, even if your system crashes at any point during a transaction. That is, after committing successfully, all your changes will persist even if there is an error after committing. Similarly, if your system crashes before committing or rolling back, then none of your updates will persist.
🗃️ Data Definition