Uploaded image for project: 'TinkerPop'
  1. TinkerPop
  2. TINKERPOP-1520

Difference between 'has' step generated graphson2.0 in java and python glv implementation

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 3.2.3
    • 3.3.0
    • python
    • None

    Description

      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:

      {"@type":"g:Bytecode","@value":{"step":[["E"],["has","weight",{"@type":"g:P","@value":{"predicate":"eq","value":{"@type":"g:Double","@value":0.2}}}]]}}
      

      where the python implementation produces the following:

       {"@type":"g:Bytecode","@value":{"step":[["E"],["has","weight",0.2]]}}
      

      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) so maybe implementors will need to do the same (python link)?

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            okram Marko A. Rodriguez
            andrew.tolbert Andy Tolbert
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment