[ https://issues.apache.org/jira/browse/TINKERPOP-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878192#comment-17878192 ]
Cole Greer commented on TINKERPOP-3109: --------------------------------------- Agreed, that description of TinkerGraph is definitely outdated and the fail() step docs would benefit from being a bit more explicit regarding the boundaries between defined and undefined behavior. I suggest we address this as part of a more holistic review of the documentation in preparation for the upcoming 3.7.3 release. > 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)