One thing I should have noted about tx().create(). The create() very well
could have been named traversal(), thus the previous example reading as:
g = traversal().withEmbedded(graph)
// or
g = traversal().withRemote(conn)
gtx = g.tx().traversal()
gtx.addV('person').iterate()
gtx.addV('software').iterate()
gtx.close() // alternatively you could explicitly commit() or rollback()
You're basically spawning a new GraphTraversalSource from the Transaction
object rather than from a Graph or AnonymousTraversal. I chose create()
because it felt like this looked weird:
g = traversal().withRemote(conn).tx().traversal()
which would be a weird thing to do I guess, but just seeing "traversal()"
over and over seemed odd looking and I wanted to differentiate with the
Transaction object even though the methods are identical in what they do. I
suppose I also drew inspiration from:
Transaction.createdThreadedTx()
which I think we might consider deprecating. JanusGraph would simply expose
their own Transaction object in the future that has that method as I
imagine folks still use that feature. As far as I know, no other graph
implements that functionality and my guess is that no one will likely do so
in the future.
anyway, if you like traversal() better than create() or the other way
around, please let me know
On Wed, Mar 17, 2021 at 5:33 PM David Bechberger <[email protected]>
wrote:
> I am in favor of this change as I any idea that unifies the multiple
> different ways things work in TP will only make it easier to learn and
> adopt.
>
> I don't know that I have enough knowledge of the inner workings of
> transactions to know what/if this will cause problems.
>
> Dave
>
> On Wed, Mar 17, 2021 at 12:57 PM Stephen Mallette <[email protected]>
> wrote:
>
> > We haven't touched "transactions" since TP3 was originally designed. They
> > have remained a feature for embedded use cases even in the face of the
> rise
> > of remote graph use cases and result in major inconsistencies that really
> > bother users.
> >
> > As we close on 3.5.0, I figured that perhaps there was a chance to do
> > something radical about transactions. Basically, I'd like transactions to
> > work irrespective of remote or embedded usage and for them to have the
> same
> > API when doing so. In mulling it over for the last day or so I had a
> > realization that makes me believe that the following is possible:
> >
> > g = traversal().withEmbedded(graph)
> > // or
> > g = traversal().withRemote(conn)
> > gtx = g.tx().create()
> > gtx.addV('person').iterate()
> > gtx.addV('software').iterate()
> > gtx.close() // alternatively you could explicitly commit() or rollback()
> >
> > // you could still use g for sessionless, but gtx is "done" after
> > // you close so you will need to create() a new gtx instance for a
> > // fresh transaction
> > assert 2 == g.V().count().next()
> >
> > Note that the create() method on tx() is the new bit of necessary syntax.
> > Technically, it is a do-nothing for embedded mode (and you could skip it
> > for thread-local auto-transactions) but all the documentation can be
> > shifted so that the API is identical to remote. The change would be
> > non-breaking as the embedded transaction approach would remain as it is,
> > but would no longer be documented as the preferred approach. Perhaps we
> > could one day disallow it but it's a bit of a tangle of ThreadLocal that
> > I'm not sure we want to touch in TP3.
> >
> > What happens behind the scenes of g.tx().create() is that in remote cases
> > the RemoteConnection constructs a remote Transaction implementation which
> > basically is used to spawn new traversal source instances with a session
> > based connections. The remote Transaction object can't support
> transaction
> > listeners or special read-write/close configurations, but I don't think
> > that's a problem as those things don't make a lot of sense in remote use
> > cases.
> >
> > From the server perspective, this change would also mean that sessions
> > would have to accept bytecode and not just scripts, which technically
> > shouldn't be a problem.
> >
> > One downside at the moment is that i'm thinking mostly in Java at the
> > moment. I'm not sure how this all works in other variants just yet, but
> I'd
> > hope to keep similar syntax.
> >
> > I will keep experimenting tomorrow. If you have any thoughts on the
> matter,
> > I'd be happy to hear them. Thanks!
> >
>
