Started this "survey" on gremlin-users to get a sense of what folks were doing:
https://groups.google.com/forum/#!topic/gremlin-users/6l9-z5g7FYI On Fri, Oct 16, 2015 at 3:25 PM, Stephen Mallette <[email protected]> wrote: > I didn't want to go to "one-and-only" talk, but I was going to go there > assuming folks were accepting of this proposal. I'd likely want to take > that discussion to gremlin-users as well. I'm wondering how many folks > unsafely do a multi-graph transaction in a single request. > > On Fri, Oct 16, 2015 at 11:04 AM, Matt Frantz <[email protected]> > wrote: > >> It would seem that we want a sort of "strict" mode where the client must >> declare the (one-and-only?) graph that they want to use. That way, we >> could deprecate support for the server-side graph names, and raise an >> exception if strict mode is enabled. It becomes sort of an "import" >> feature from the client standpoint, i.e. they must import a graph to use >> it. >> >> On Thu, Oct 15, 2015 at 12:32 PM, Stephen Mallette <[email protected]> >> wrote: >> >> > The current "tranaction manager" in Gremlin Server is just like >> Rexster's >> > and it's not very smart. It makes no distinction about what graphs were >> > actually affected when it issues its auto-commits/rollbacks at the end >> of a >> > sessionless request. For those with a number of different Graph >> instances >> > configured in Gremlin Server, that's a lot of extra empty commits if the >> > intent is to just mutate a single graph in the set. I'm not sure what >> that >> > time amounts to, but it seems sensible that if we could only commit when >> > needed then it would be better than lots of extra commits for nothing. >> > >> > As it so happens we have the rebindings feature (wonder why didn't call >> > that "alias") in Gremlin Server: >> > >> > http://tinkerpop.incubator.apache.org/docs/3.0.1-incubating/#_rebinding >> > >> > So we could use that to tell the transaction manager which graph the >> user >> > is working with and thus allow the correct commit on the right graph. >> If >> > no rebindings are supplied, I guess we could stick with the current >> model. >> > >> > It is a potentially breaking change to people already using rebindings >> only >> > in the sense that if they have two graphs in Gremlin Server, then chose >> to >> > use a rebind for one, but then issued scripts that directly referenced >> the >> > other, obviously, under this new model, the transaction would be >> > uncommitted on the direct reference - they would have to alter the code >> to >> > rebind both. >> > >> > Generally speaking, I think we want to encourage rebinding as a pattern >> as >> > it makes code more flexible as your scripts don't get bound to the name >> of >> > the graph in Gremlin Server - they can be bound to a more general alias. >> > So this change would perhaps lead folks in this direction. >> > >> > Anyone against using rebindings in that fashion? >> > >> > >
