Christopher Smith created TINKERPOP-3109:
--------------------------------------------
Summary: Writes succeed even when query fail()s
Key: TINKERPOP-3109
URL: https://issues.apache.org/jira/browse/TINKERPOP-3109
Project: TinkerPop
Issue Type: Bug
Components: tinkergraph
Affects Versions: 3.7.2
Reporter: Christopher Smith
This may be a fundamental limitation of the non-transactional design of
TinkerGraph, in which case I would request a more detailed writeup on the
{{fail()}} step itself.
I am trying to test a query where if all edges are removed from a vertex, the
query should fail (to avoid an orphaned resource):
{code:java}
// drop some edges
.select('v').coalesce(__.in('Manages').limit(1), fail('all edges
removed')){code}
In Neptune, the {{fail()}} step results in a rollback of the entire query so
that the edges are not removed. In TinkerGraph, the query still fails (and I
get my expected HTTP 409 response), but the graph changes are applied.
If this is unavoidable (e.g., no ability to roll back state once a {{drop()}}
has been executed), then please add a note to the reference documentation for
{{fail()}} mentioning that whether changes up to that point persist is
implementation-specific.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
