Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
3.7.2
-
None
-
None
Description
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):
// drop some edges .select('v').coalesce(__.in('Manages').limit(1), fail('all edges removed'))
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.