SQL Changes
DISTINCT keyword
In v 2.2 the only way to have distinct values from a SELECT statement was using the distinct() function.
In v 3.0 we introduced DISTINCT operator, that is much more flexible than distinct() function.
The following query is valid in v 3.0
SELECT DISTINCT name, surname from Person
distinct() function is still allowed, but it's deprecated
eval() and mathematical expressions
Until v 2.2 the only way to execute mathematical operations in SQL was to use eval(expression) function:
SELECT eval(' 3 + 2 ') as sum
In v 3.0 mathematical expressions are allowed in both projections and WHERE conditions, eg.
SELECT 3 + 2 as sum
SELECT FROM V WHERE theNumber > 3 + 3
Please refer to SQL syntax page for all the details
MATCH and DISTINCT
In v.2.2 the MATCH statement automatically filters duplicate result rows and there is no way to specify a different behavior.
In v 3.0 the MATCH by default ALLOWS duplicate results, if you want only distinct results you have
to explicitly declare RETURN DISTINCT ...
The following statement in v.2.2
MATCH
{class:Person, as:a} -FriendOf-> {as:b}
RETURN a.name, b.name
is equivalent to v. 3.0
MATCH
{class:Person, as:a} -FriendOf-> {as:b}
RETURN DISTINCT a.name, b.name
Changes in the CREATE INDEX statement
CREATE INDEX T.id UNIQUE
is not allowed anymore, please use
CREATE INDEX T.id ON T(id) UNIQUE
instead
Changes in the way batch script commands are separated
In v. 2.2 the newline is a valid statement separator in batch scripts.
Since 3.0 the only valid statement separator is the semicolon ;.
In v 3.0 the following script is invalid
SELECT FROM V
SELECT FROM E
The following script is valid as well
SELECT FROM V
WHERE name = 'foo';
SELECT FROM E;
Please note that the first statement is split on two rows.
EXPLAIN
BREAKING CHANGE: in v. 3.0 the EXPLAIN statement does not execute the statement anymore and does not return information about execution statistics.
The EXPLAIN statement in v 3.0 returns details about the execution planning for the query, ie. all the steps that the query executor will execute to calculate the query result.
Changes in the CREATE EDGE statement
Starting from 3.0, it is mandatory to create the Edge class before executing the CREATE EDGE statement. If the Edge class does not exist the CREATE EDGE statement will fail (previously it was creating the Edge class automatically).
Changes in the DELETE EDGE statement
Starting from 3.0, it is mandatory to specify in the DELETE EDGE statement the Edge class of the edge instance you want to delete. If the Edge class is not specified the DELETE EDGE statement will fail. So if until 2.2.x Edge class is optional and you can execute something like
DELETE EDGE WHERE out=#9:0 AND in=#10:1
in 3.0 Edge Class is mandatory:
DELETE EDGE <Edge-Class-Name> WHERE out=#9:0 AND in=#10:1
To delete all edges from two specific vertices regardless of their Edge class you can simply specify the 'E' Edge Class:
DELETE EDGE E WHERE out=#9:0 AND in=#10:1