i don't think so. we've been consistent in saying that we don't want to add properties to elements when a full Gremlin Traversal Machine isn't in the host programming language of the particular GLV.
On Wed, Oct 24, 2018 at 10:05 AM [email protected] <[email protected]> wrote: > > > On 2018/10/22 18:21:13, Stephen Mallette <[email protected]> wrote: > > 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 > > >> > > > > > > Just for completeness is it an option to support detached elements for > GLVs? > > If GLVs did support detached elements then this would significantly reduce > the impact of this change for users as this would mostly align with what > they have now. > > >
