[
https://issues.apache.org/jira/browse/TINKERPOP-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877902#comment-17877902
]
Christopher Smith commented on TINKERPOP-3109:
----------------------------------------------
I had missed the new development! The documentation still states that
"TinkerGraph is a single machine, in-memory (with optional persistence),
non-transactional graph engine". I will give it a try (but the fail()
semantics could still use better documentation, clarifying whatever the
actual case is).
--
Christopher Smith
> 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)
