This page documents the supported openCypher Syntax that BloodHound officially supports
=
<>
<
>
<=
>=
Differences between Cypher and CySQL
subsection Stricter Typing Requirements
.
not
operator:
and
and disjunction or
operators are both supported:
collect
count
duration
Functionid
Functionlocaltime
localdatetime
date
datetime
type
split
tolower
toupper
tostring
toint
coalesce
null
behavior between Cypher and CySQL.
size
size
function is expected to behave differently if the given expression evaluates to a text value. In this case,
the function returns the number of Unicode characters present in the text value. This behavior is currently not
supported in CySQL translation.
create
reserved Cypher keyword is currently unsupported. Future support of it is planned.
labels
Functionhead
, tail
and last
are not currently supported These functions are typically used to
reference different parts of a matched pattern.
Support for them is planned for a future version of CySQL.
ERROR: column notation .id applied to type nodecomposite[], which is not a composite type (SQLSTATE 42809)
.
ERROR: invalid reference to FROM-clause entry for table "s0" (SQLSTATE 42P01)
.
Error: array literal has no available type hints
.
match (n:User) where n.name = 123 return n limit 1;
The translated SQL, when executed, results in the following error:
Error: ERROR: invalid input syntax for type bigint: "MYUSER@DOMAIN.COM" (SQLSTATE 22P02)
This indicates that there is a node with a value for n.name
that is not parsable as an integer.
In the future, CySQL translation will cover most of the strict typing requirements automatically for users.
name
is indexed in CySQL,
both:
name
index regardless of node label.
null
in SQL differs from how Neo4j executes Cypher. Certain expression operators in Neo4j’s
implementation of Cypher will treat null
differently than their SQL counterparts while some semantics are very
similar.
Ideally, entity properties should strive to remove null
as a conditional case as much as possible. In cases where this
is not possible, users are advised to exercise the coalesce(...)
function:
null
can taint result sets and also further complicate future comparisons in the query:
n
is being projected by the multipart with
statement but this projection removes the resultset from
the original query, allowing for ambiguity to slip into future operations against n.name
where some values of
n.name
may be null
.