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