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

Reply via email to