The second Gremlin query should not return anything as you set the name
property "john". You didn't commit but you are in the same transaction as
that change is occurring on the same thread. if you had executed:
Vertex me2 = g.V().has("name", "martin").toSet().iterator.next();
on a different thread, and your setting the "name" property to "john" did
not yet commit then you would get a result.
On Wed, Dec 2, 2015 at 8:26 AM, Martin Häusler <[email protected]>
wrote:
> Hi,
>
> I'm currently developing an implementation for the Gremlin 3.x API which
> supports full ACID transactions. The problem I am currently facing is the
> graph transaction context. Assume that the following happens:
>
> Graph g = ... ; // acquire empty graph
> g.addVertex("name", "martin");
> g.commit();
>
> Vertex me = g.V().has("name", "martin").toSet().iterator.next();
> me.property("name", "john");
> // note: no g.commit() here!
>
> Vertex me2 = g.V().has("name", "martin").toSet().iterator.next(); // is
> this supposed to work?
>
>
> The question that arises here is: should the second gremlin query return
> the vertex? On the one hand, in the current transaction context, the vertex
> data has been changed - on the other hand, it has not been committed yet.
> Neither variant is more "correct" than the other, and the API documentation
> tells little about these issues. Moreover, TinkerGraph as the reference
> implementation does not support transactions. How should this be handled?
> Is there some common consensus among gremlin vendors?
>
> Kind regards,
> Martin
>
