[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
[
https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15597614#comment-15597614
]
stephen mallette commented on TINKERPOP-1474:
-
I was a bit surprised that [~dmill] and [~davebshow] weren't interested in
seeing properties in the GLVs.
This issue is so weird. I feel like I've argued for both sides of the fence on
it.
We've determined that Gremlin Server will, as a configuration per request,
return properties or not. We seemed to be going down the path where the default
would be to not return properties as for 3.3.0 and that there would be an
option to include properties per request. So from the server perspective the
data is available if a GLV wanted to provide it.
It does seem incongruent that the java version of {{withRemote}} has the
ability to deal with properties (even if that won't be the future default) but
the other language variants will not. It don't think that there is much more
code to manage to have the properties on those GLV structure classes. I would
think that we would draw the line at these classes being read-only of course.
It's not as though you would implement {{Vertex.addEdge()}} or those types of
methods.
> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave
> some question about what *should* be returned from a simple traversal like
> `g.V()`.
> The java implementation presently assumes that properties could be present
> and returns a DetachedVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more
> reminiscent of a ReferenceVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align
> these APIs?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1506) Optional/Coalesce should not allow sideEffect traversals.
[
https://issues.apache.org/jira/browse/TINKERPOP-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15597581#comment-15597581
]
Daniel Kuppitz commented on TINKERPOP-1506:
---
These comments still hold true. {{optional}} and {{coalesce}} are not
interchangeable.
{noformat}
gremlin> g.V().coalesce(out("knows"), identity()).coalesce(out("created"),
identity()).path()
==>[v[1],v[2],v[2]]
==>[v[1],v[4],v[5]]
==>[v[1],v[4],v[3]]
==>[v[2],v[2],v[2]]
==>[v[3],v[3],v[3]]
==>[v[4],v[4],v[5]]
==>[v[4],v[4],v[3]]
==>[v[5],v[5],v[5]]
==>[v[6],v[6],v[3]]
gremlin> g.V().optional(out("knows")).optional(out("created")).path()
==>[v[1],v[2]]
==>[v[1],v[4],v[5]]
==>[v[1],v[4],v[3]]
==>[v[2]]
==>[v[3]]
==>[v[4],v[5]]
==>[v[4],v[3]]
==>[v[5]]
==>[v[6],v[3]]
{noformat}
> Optional/Coalesce should not allow sideEffect traversals.
> -
>
> Key: TINKERPOP-1506
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1506
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>
> It took me a long time to realize what was wrong with a traversal I wrote
> that used {{optional(blah.sideEffect.blah)}}. {{optional()}} maps to
> {{ChooseStep}} under the hood and the provide traversal is first tested for a
> {{hasNext()}}. If so, the it plays itself out. The problem is that if there
> is a side-effect in the traversal child, then it gets executed twice.
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).optional(addV('twin'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin]
> ==>[id:1,label:twin]
> {code}
> We should NOT allow {{optional()}} to have {{SideEffectStep}} steps in it so
> as not to cause unexpected behavior. {{StandardVerificationStrategy}} can
> analyze and throw an exception if necessary.
> Also, {{coalesce()}} has a similar problem, though perhaps it can be a useful
> 'technique.'
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).coalesce(addV('twin1').limit(0), addV('twin2'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin1]
> ==>[id:1,label:twin2]
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
