> I'd like to propose 2a. Update Gremlin Server and TinkerGraph to behave in the desired way, this would set the tone for all Graph implementations to eventually adopt this consistent behaviour.
a little scary, but i see your point. if we went that far then i guess we would also do neo4j. i will say that this change will be on the same order of effort as 1 because it will break a lot of tests in the test suite. in that sense, i'm not sure we're ready for that much change along 3.4.0. i'd propose that we consider "2a" only after we get "2" into place. Then we can determine how much damage 1 would do. Maybe it's not as bad as I think. An interesting side-effect of 1 is that it makes our Java test suite tests become more in line with the GLV tests - they would be roughly 1 to 1 match in assertions after all this. On Fri, Oct 5, 2018 at 11:21 AM [email protected] <[email protected]> wrote: > > > On 2018/10/03 17:06:16, Stephen Mallette <[email protected]> wrote: > > We currently have this situation where users get a fair bit of > > inconsistency around the contents of graph elements depending on a matrix > > of different usage options that we offer - here's just a few "options" as > > examples: > > > > 1. Use embedded graph mode in OLTP and you likely get the implementation > > version of a Vertex/Edge with accessible properties (e.g. TinkerVertex, > > Neo4jVertex, etc) > > 2. Use embedded graph mode in OLAP and you get ReferenceVertex/Edge with > no > > properties > > 3. Use bytecode based requests with Gremlin Server and you get > > ReferenceVertex/Edge with no properties > > 4. Use script based requests with Gremlin Server and you get > > DetachedVertex/Edge with properties > > > > All this chaos developed out of a healthy evolution of our view of "how > > Gremlin should work and how it fits in the graph community." As I've > > lamented before and I'll lament again, that if we'd foreseen "bytecode", > > then a lot of things would have been more unified. > > > > Anyway, irrespective of how we got here, I think this matrix of choices > > ends up making things quite confusing for users. > > > > To unify and simplify in 3.4.0, I think we could introduce a > > ReferenceStrategy which would coerce graph elements to the "Reference". > > Then we have some choices: > > > > 1. In the most extreme case, it could be installed as a default strategy. > > All graphs was return the same stuff in whatever situation it was used. > > Obviously, that breaks just about every test in existence and probably > half > > of the code on the planet that uses TinkerPop - everyone ready to not get > > amazon packages delivered on time anymore over this? But, we're > consistent! > > :) > > 2. We install it as a default strategy in graphs in Gremlin Server. > Still a > > breaking change but at least Gremlin Server is completely consistent. > Users > > can uninstall the strategy if they don't like it and stuff will work as > it > > always did. > > 3. We simply supply ReferenceStrategy as an option and let users install > it > > for themselves to help bring greater consistency to their installations. > > > > I think we should consider option 2. Unless someone has other options to > > consider, it seems like the easiest starting point for this that will > > actually have an impact. There could be devils lying in wait in the > > details, but I thought I'd feel folks on a bit on the general idea. > > > > Thanks, > > > > Stephen > > > > > The thing that worries me is that to go for option 2 still leaves > TinkerGraph behaving in a way that is not consistent over the wire. > > The first thing that many users will do is fire up gremlin console and > create a TinkerGraph without Gremlin Server. This immediately give them a > false impression that properties on elements are available. > > I'd like to propose 2a. Update Gremlin Server and TinkerGraph to behave in > the desired way, this would set the tone for all Graph implementations to > eventually adopt this consistent behaviour. > > Bryn >
