You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Andy Tolbert (JIRA)" <ji...@apache.org> on 2016/10/18 17:04:58 UTC
[jira] [Created] (TINKERPOP-1520) Difference between 'has'
generated graphson2.0 in java and python glv implementation
Andy Tolbert created TINKERPOP-1520:
---------------------------------------
Summary: Difference between 'has' 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
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)