https://issues.apache.org/jira/browse/TINKERPOP-2075
On Mon, Oct 8, 2018 at 1:37 PM Stephen Mallette <[email protected]> wrote: > > 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 >> >
