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 19:48:58 UTC

[jira] [Commented] (TINKERPOP-1520) Difference between 'has' step generated graphson2.0 in java and python glv implementation

    [ https://issues.apache.org/jira/browse/TINKERPOP-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15586488#comment-15586488 ] 

Andy Tolbert commented on TINKERPOP-1520:
-----------------------------------------

Just to correctly my previous comment.  The query appears to work correctly in both cases (whether a predicate is used or not), but would still be good for the behavior to be consistent across implementations.

> 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)