[
https://issues.apache.org/jira/browse/TINKERPOP-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877897#comment-17877897
]
Cole Greer commented on TINKERPOP-3109:
---------------------------------------
Whether fail() triggers a rollback is indeed implementation dependent. I agree
that this is something which should be made more clear in the documentation.
Basic TinkerGraph is incapable of such a rollback as it does not maintain any
history of changes to be reversed. However, 3.7.0 introduced a variant of
TinkerGraph with transactional support
(https://tinkerpop.apache.org/docs/3.7.0/reference/#tinkergraph-gremlin-tx). I
don't know off the top of my head if the fail() semantics in transactional
TinkerGraph are the same as basic TinkerGraph by persisting changes, or if it's
more similar to an implementation like Neptune with rollbacks.
> 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
> Priority: Minor
>
> 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)
