Hi Stephen, More the latter. TinkerPop transactions would be layered on top of the native transactions of the database (if any), which gives the VM more control over the operational semantics of a computation in between database commits. For example, in many scenarios it would be desirable not to mutate the graph at all until a traversal has completed, so that the result does not depend on the order of evaluation. Consider a traversal which adds or deletes elements as it goes. In some cases, you want writes and reads to build on each other, so that what you wrote in one step is accessible for reading in the next step. This is a very imperative style of traversal for which you need to understand how the VM builds a query plan in order to predict the result. In many other cases, you might prefer a more functional approach, for which you can forget about the query plan. Without VM-level transactions, you don't have this choice; you are at the mercy of the underlying database. The extra level of control will be useful for concurrency and parallelism, as well -- without it, the same programs may have different results when executed on different databases.
Josh On Wed, May 15, 2019 at 6:47 AM Stephen Mallette <[email protected]> wrote: > Hi Josh, interesting... we have graphs with everything from no transactions > like TinkerGraph to more acid transactional systems and everything in > between - will transaction support as you describe it cover all the > different transactional semantics of the underlying graphs which we might > encounter? or is this an approach that helps unify those different > transactional semantics under TinkerPop's definition of a transaction? > > On Wed, May 15, 2019 at 9:23 AM Joshua Shinavier <[email protected]> > wrote: > [...]
