Malformed id in g.V().hasId()

[vitalych]

Using the given example and the default janusgraph docker image, I get the following error:

$ docker run -it -p 8182:8182 janusgraph/janusgraph

$ ./vertex-edge-example -h ws://127.0.0.1:8182
2020-04-17T20:01:06.525+0200    FATAL   vertex-edge-example/main.go:89  Error while querying for outer edges    {"error": "{\"type\":\"NETWORK_ERROR\"},{\"status code\":\"597\"},{\"error\":\"SCRIPT EVALUATION ERROR\"},{\"original error\":\"startup failed:\nScript7.groovy: 1: unexpected token: : @ line 1, column 22.\n   g.V().hasId(map[@type:g:Int64 @value:4144]).outE()\n                        ^\n\n1 error\n\"}"}

[caffix]

This library is incredible, but unfortunately, I am experiencing the same problem as @vitalych

[slooker]

I also have the same problem. It looks like ID() doesn't actually return what it's supposed to. Here's a simple example:

package main

import (
    "github.com/northwesternmutual/grammes"

    "fmt"
    "log"
)

func main() {
    client, err := grammes.DialWithWebSocket("ws://127.0.0.1:8182")

    // Adding two testing vertices.
    vertex1, err := client.AddVertex("person1", "name", "damien")
    if err != nil {
        log.Fatal("Failed to add vertex: ", err)
    }

    fmt.Println("ID: ", vertex1.ID())
}

This prints out ID: map[@type:g:Int64 @value:40161]

[damienfamed75]

@vitalych @caffix @slooker please try using v1.1.2 and come back with your results.

[caffix]

I went back to that version after our last conversation and was successful. Thank you!

Are you still planning for a release that can handle all the various Gremlin servers/services?

[damienfamed75]

@caffix yes I've been playing around for a design of Grammes v2 that should solve this issue

[caffix]

Great! I appreciate the excellent library and your assistance

[slooker]

Any idea when Grammes v2 may be coming out? I can't use 1.1.2 because it doesn't support Neptune, and I'm having to do a lot of workarounds for 1.2.0 since ID() doesn't seem to work correctly.

[rogaha]

same here

[jhole89]

@damienfamed75 I'm also having the same issue and was reviewing #16 however wondered if yourself or @aciduck could clear a question up for me. Why did #16 change the VertexID from a struct that would map out the ID value correctly, to an interface?

The only docs I can find around ID differences is from https://docs.aws.amazon.com/neptune/latest/userguide/access-graph-gremlin-differences.html#w3aac12c20c10c15c25

Neptune Gremlin Vertex and Edge IDs must be of type String.

It doesn't say so but based on the changes in #16 does this mean that Neptune returns the id part as {"@type":"g:Vertex","@value":{"id": "some-string"}} instead of "{"@type":"g:Vertex","@value":{"id":{"@type":"g:String","@value": "some-string"}}} ?

I assume if this is not the case and Neptune returns the second Gremlin complaint response then its just a simple case of reverting #16 and changing the Value types from Int64 to interface rather than removing the entire struct?

[rwsegura]

I have a pull request that will make v1.2.0 work with local gremlin and aws neptune:

https://github.com/northwesternmutual/grammes/pull/40

Edit: to add some insight @jhole89 I attempted to do as such in my own fork to test and that was now the case Neptune returns {"@type":"g:Vertex","@value":{"id": "some-string"}} it seems.

My change in my pull request checks if the id is a map or string and base on that will return correctly