[
https://issues.apache.org/jira/browse/TINKERPOP-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15687196#comment-15687196
]
ASF GitHub Bot commented on TINKERPOP-1520:
-------------------------------------------
Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/499
> If we do this, then we would have to change Edge back to the same model
to be consistent
Indeed.
> why change it back?
Because currently it is not consistent,
(Detached)Edge/Vertex/VertexProperty all derive from (Detached)Element, for
which `properties` have the same structure, but with what's currently on the
PR, Edge and VertexProperty don't have their `properties` serialized in the
same format than Vertex.
If we unify all we can make generalize the deserialization of an object
that derives from Element and make the deserialization code more readable.
In my opinion I don't believe verbosity should be chosen over consistency
here, especially since GraphSON 2 is already very very verbose and not really
meant to be compact.
> Difference between 'has' step generated graphson2.0 in java and python glv
> implementation
> -----------------------------------------------------------------------------------------
>
> Key: TINKERPOP-1520
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1520
> Project: TinkerPop
> Issue Type: Bug
> Components: language-variant
> Affects Versions: 3.2.3
> Reporter: Andy Tolbert
>
> Noticed that between the java and python implementations, the graphson2.0
> payload generated for a {{has}} step is different. i.e. for the given
> traversal:
> {{g.E().has("weight", 0.2)}}
> The java implementation produces the following graphson:
> {code:javascript}
> {"@type":"g:Bytecode","@value":{"step":[["E"],["has","weight",{"@type":"g:P","@value":{"predicate":"eq","value":{"@type":"g:Double","@value":0.2}}}]]}}
> {code}
> where the python implementation produces the following:
> {code:javascript}
> {"@type":"g:Bytecode","@value":{"step":[["E"],["has","weight",0.2]]}}
> {code}
> In the java case, a {{g\:P}} typed (predicate) value is provided, where in
> the python case that isn't the case.
> I'm assuming the java one is correct (primarily since the graph backend seems
> to like it and return the expected result). Should GLV implementations
> behave this way? I noticed that {{GraphTraversal#has(String propertyKey,
> Object value)}} in the java TinkerPop api wraps the value in a predicate
> ({{P.eq}}) under the covers
> ([link|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L922])
> so maybe implementors will need to do the same ([python
> link|https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/process/graph_traversal.py#L193])?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
