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 <spmalle...@gmail.com> 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? >
