[ https://issues.apache.org/jira/browse/TINKERPOP-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cole Greer updated TINKERPOP-3109: ---------------------------------- Component/s: documentation (was: tinkergraph) > 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: documentation > 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)