My survey didn't get very far. One response in who uses multiple graphs in single requests. I'd expected more, but perhaps that feature isn't really being used. I think that having some kind of "mode" as Matt suggested would be good. Anyway - i've written up the ticket as such:
https://issues.apache.org/jira/browse/TINKERPOP3-930 and the "old way" can be preserved - for now. On Tue, Oct 20, 2015 at 8:38 AM, Stephen Mallette <[email protected]> wrote: > 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? >>> > >>> >> >> >
