Databases Reference
In-Depth Information
The
WHERE
clause in the query before the
UNION
operator once again eliminates matches
where the
company
in question is connected to one of the administrator's groups by way
of a
DENIED
relationship.
Because the
UNION
operator eliminates duplicate results, the overall result set for this
query can contain either one or two values. The client-side logic for determining
whether an administrator has access to a resource looks like this in Java:
private
boolean
isAuthorized
(
ExecutionResult
result
)
{
Iterator
<
Long
>
accessCountIterator
=
result
.
columnAs
(
"accessCount"
);
while
(
accessCountIterator
.
hasNext
()
)
{
if
(
accessCountIterator
.
next
()
>
0L
)
{
return
true
;
}
}
return
false
;
}
Finding administrators for an account
The previous two queries represent “top-down” views of the graph. The last TeleGraph
query we'll discuss here provides a “bottom-up” view of the data. Given a resource—an
employee or account—who can manage it? Here's the query:
START
resource=
node
:resource(name=
{resourceName}
)
MATCH
p=(resource)-[:WORKS_FOR|HAS_ACCOUNT*1..2]-(company)
-[:CHILD_OF*0..3]->()<-[:ALLOWED_INHERIT]-()<-[:MEMBER_OF]-(admin)
WHERE
NOT
((admin)-[:MEMBER_OF]->()-[:DENIED]->()<-[:CHILD_OF*0..3]-(company))
RETURN
admin.name
AS
admin
UNION
START
resource=
node
:resource(name=
{resourceName}
)
MATCH
p=(resource)-[:WORKS_FOR|HAS_ACCOUNT*1..2]-(company)
<-[:ALLOWED_DO_NOT_INHERIT]-()<-[:MEMBER_OF]-(admin)
RETURN
admin.name
AS
admin
As before, the query consists of two independent queries joined by a
UNION
operator.
Of particular note are the following clauses:
• The
START
clauses use a
resource
index, a named index for both employees and
accounts.
• The
MATCH
clauses contain a variable-length path expression that uses the
|
operator
to specify a path that is one or two relationships deep, and whose relationship types
comprise
WORKS_FOR
and
HAS_ACCOUNT
. This expression accommodates the fact that
the subject of the query may be either an employee or an account.
