[
https://issues.apache.org/jira/browse/TINKERPOP-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-3109.
---------------------------------------
Resolution: Workaround
doc updates:
https://github.com/apache/tinkerpop/commit/019b860464e74bc6ece840ab709a474573bbdb7f
https://github.com/apache/tinkerpop/commit/c4557a657a83c872da1ef6fe25f1c46f15ff3b75
note that TinkerGraph configured with transactions seems to get the rollback
right for this specific case:
{code}
gremlin> gtx = g.tx().begin()
==>graphtraversalsource[tinkertransactiongraph[vertices:6 edges:6], standard]
gremlin> gtx.V().as('v').sideEffect(outE().drop()).coalesce(bothE(), fail('all
edges removed'))
fail() Step Triggered
====================================================================================================================
Message > all edges removed
Traverser> v[1]
Bulk > 1
Sack > null
Loops > {null=0}
S/E > {}
Traversal> fail("all edges removed")
Parent > CoalesceStep
[V().as("v").sideEffect(__.outE().drop()).coalesce(__.bothE(),__.fail("all
edges removed"))]
Metadata > {}
====================================================================================================================
gremlin> gtx.E()
==>e[10][4-created->5]
==>e[11][4-created->3]
==>e[12][6-created->3]
gremlin> gtx.tx().rollback()
==>null
gremlin> g.E()
==>e[7][1-knows->2]
==>e[8][1-knows->4]
==>e[9][1-created->3]
==>e[10][4-created->5]
==>e[11][4-created->3]
==>e[12][6-created->3]
{code}
> 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)
