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

Gremlin Javascript deserialize Long into Number but then serializes Number into Integer

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 3.5.5
    • None
    • javascript
    • None

    Description

      Currently, javascript cucumber test suite need the server to have vertexIdManager set to INTEGER or ANY, or else there will be failing tests.

      This appears to be due to javascript deserializing LONG type vertex ID into its native Number type, and storing the vertex ID as a Number:

      getting vertex object from server
      {
        '@type': 'g:Vertex',
        '@value': { id: { '@type': 'g:Int64', '@value': 1 }, label: 'person' }
      }
      deserialized vertex id is of type
      number

      So when the cucumber test queries the graph by the vertex, javascript serializes the Number vertex ID as an INTEGER, and since TinkerGraph requires the exact type of vertex IDs to match(i.e. a LONG), we get empty result and failed tests:

      serialize vertex id is of type
      number
      serializing this
      1
      serializing this
      { '@type': 'g:Vertex', '@value': { id: 1, label: 'person' } }
      serializing this
      { '@type': 'g:Bytecode', '@value': { step: [ [Array], [Array] ] } }
      listing result for
      g.V(v1).bothE()
      []
      F-

      So this forces javascript tests to use a server configuration of gremlin.tinkergraph.vertexIdManager=INTEGER or gremlin.tinkergraph.vertexIdManager=ANY in order to pass the cucumber tests. The same failure will occur with GraphBinary as the logic runs the same. 

       

      This looks specific to javascript due to the Number typing. I’ve tested this with the go driver to confirm, which passes cucumber tests with either LONG or INTEGER vertexIdManager, as it deserializes the vertex IDs into matching types.

      I've confirm in a separate query that with the LONG vertexId Manager, if we create a vertex with toLong(vertexID), the query will be successful, e.g. 

      g.V(new Vertex(toLong(1))).bothE() 
      serialize vertex id is of type
      object
      serializing this
      { '@type': 'g:Int64', '@value': '1' }
      serializing this
      {
        '@type': 'g:Vertex',
        '@value': { id: { '@type': 'g:Int64', '@value': '1' }, label: undefined }
      }

      I assume the fix would involve either using the toLong() function appropriately, or if it is possible, to create a custom Long type that can be used when serializing/deserializing. 

      Attachments

        Activity

          People

            Unassigned Unassigned
            xiazcy Yang Xia
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: