Gremlin driver returns invalid RID's (at least when called using Bytecode streams)

[amoorthaemer]

OrientDB Version: 3.0.0RC2

Java Version: 9.0.1

OS: Windows 10 Enterprise

Expected behavior

When adding a vertex using Germlin's g.addV() (using 'Bytecode') I expect that the RID that is returned is a RID which I can use to find the vertex using g.V()

Actual behavior

When I add a new vertex with Gremlin's g.addV() I get a RID that has a cluster position value of -2. Hence I can't find the vertex with g.V() and adding edges therefore all fail (or every other action I try to do using RID's)

Steps to reproduce

1. Add a new vertex with g.addV()
2. Try to find the vertex with g.V()

[wolf4ood]

hi @amoorthaemer

from gremlin console ? or rest api? or websocket?

Thanks

[amoorthaemer]

hi @maggiolo00.

Web socket it is ...

Cheers

Bert

[wolf4ood]

@amoorthaemer

did you install the driver in the gremlin server or
did you use directly the embedded version of the Gremlin Sever shipped with RC2?

[amoorthaemer]

@maggiolo00

I'm using the embedded version ... Actually I only added a new database and pointed the "g" global to it

I send this ...

{
  "requestId": "0f65d9f4-03b5-45c8-9947-490ecde9060f",
  "op": "bytecode",
  "processor": "traversal",
  "args": {
    "gremlin": {
      "@type": "g:Bytecode",
      "@value": {
        "step": [
          [
            "addV",
            "person"
          ],
          [
            "property",
            "firstName",
            "Robin"
          ],
          [
            "property",
            "lastName",
            "Wakefield"
          ],
          [
            "property",
            "age",
            {
              "@type": "g:Int32",
              "@value": 44
            }
          ]
        ]
      }
    },
    "aliases": {
      "g": "g"
    }
  }
}

... and receive this ...

{
   "requestId":"0f65d9f4-03b5-45c8-9947-490ecde9060f",
   "status":{
      "message":"",
      "code":200,
      "attributes":{
         "@type":"g:Map",
         "@value":[

         ]
      }
   },
   "result":{
      "data":{
         "@type":"g:List",
         "@value":[
            {
               "@type":"g:Traverser",
               "@value":{
                  "bulk":{
                     "@type":"g:Int64",
                     "@value":1
                  },
                  "value":{
                     "@type":"g:Vertex",
                     "@value":{
                        "id":{
                           "@type":"orient:ORecordId",
                           "@value":"#40:-2"
                        },
                        "label":""
                     }
                  }
               }
            }
         ]
      },
      "meta":{
         "@type":"g:Map",
         "@value":[

         ]
      }
   }
}

Actualy RID in the database is: #40:5

As you can see the "label" is also empty (which should be "person"??)

[amoorthaemer]

@maggiolo00

Ok, got some more info for you ... It seems the RID I get from g.addV() is something temporary, because when I retrieve the Vertex with some kind of other unique property I get the right RID. But, the label property is still empty

Cheers

Bert

[wolf4ood]

Ok @amoorthaemer

let me check it. Thanks

[amoorthaemer]

Ok

Another observation ... when updating a vertex or adding an edge between two vertices I get a version conflict when trying to access either of the two involved vertices ... To overcome that I have to either reload the vertices or restart the whole server ... I guess this has something to do with "Gremlin"-side caching??

Cheers and happy hunting ...

[wolf4ood]

@amoorthaemer

How do you update/ add edge?

[amoorthaemer]

Adding/update an edge with something like:

g.V(id1).addE('knows').property('weight', 1.0).to(g.V(id2))

When trying to execute this command I need to reload the vertex with id1 and id2. If I don't do this and I would try to add another edge to f.e. id1 I get a version conflict exception.

Same for g.V().drop() or any other command that involves vertices with updated versions ...

Cheers

[wolf4ood]

Hi @amoorthaemer

i've found the problem for version conflict, i will push a fix soon.

For the rids problem, i've reproduced it . Seems more difficult to solve.
OrientDB generates temporary rids in transactions and then are resolved into valid rids at commit time.

The problem that i discovered in a debug session is that the result of the traversal (addV in your case)
is first serialized on the network and the the .commit() is call on the graph. That is why you get a temporary rid.

Let me check for possible solutions

Thanks

[amoorthaemer]

Ok tnx ... If I come across more issues I will let you know

[amoorthaemer]

hi @maggiolo00

I think I found another issue... It concerns path traversal... Let me explain

Suppose I have 4 vertices (v1 up-to v4) which have following edges:
v1 -> v2 (edge weight: 1.0)
v1 -> v3 (edge weight: 0.5)
v2 -> v4 (edge weight: 0.2)
v3 -> v4 (edge weight: 0.1)

Now I want all paths from v1 to any "ending" vertex where the edge weight must be greater than 0.1
When I do in f.e. Azure CosmosDB (and also to be found as the solution on the internet):

g.V(v1.id).repeat(outE('edge').has('weight', gt(0.1)).inV()).until({some condition}).path()

I get:

v1->v2->v4
v1->v3

which is the wanted answer, but with OrientDB I get:

v1->v2
v1->v3

It seems that the until() is short circuiting prematurely... Or, if I'm wrong ... do you have a better solution for this?

/Cheers
Bert

[wolf4ood]

@amoorthaemer

thanks for reporting this i will dig on it tomorrow

[wolf4ood]

@amoorthaemer

which was the condition that you tried in the until ?

Thanks

[amoorthaemer]

@maggiolo00

outE("edge").has("weight", lte(0.1))

[amoorthaemer]

@maggiolo00

Rectification ...

or(outE("edge").count().is(0), outE("edge").has("weight", lte(0.1)))

[wolf4ood]

Hi @amoorthaemer

i've run this script for populating your test graph

v1 = graph.addVertex("id",1);
v2 = graph.addVertex("id",2);
v3 = graph.addVertex("id",3);
v4 = graph.addVertex("id",4);

v1.addEdge("edge",v2,"weight",1.0)
v1.addEdge("edge",v3,"weight",0.5)
v2.addEdge("edge",v4,"weight",0.2)
v3.addEdge("edge",v4,"weight",0.1)

and the run

g.V().has("id",1).repeat(outE('edge').has('weight', gt(0.1)).inV()).until(or(outE("edge").count().is(0), outE("edge").has("weight", lte(0.1)))).path()

The result seems correct.

Do you have a script to reproduce the issue?

Thanks

[amoorthaemer]

Hi @maggiolo00,

Hmmmm, it seems something else is the problem ... When I run the script multiple times with strictTransactionManagement: true I get (in random order):

1. No results
2. One result
3. Two results (incomplete paths)
4. Two results (complete paths)

With strictTransactionManagement: false I get the right result (#4) every time ..

Hope this helps

Cheers
Bert

[wolf4ood]

Hi @amoorthaemer

i've tried also with

strictTransactionManagement: true

seems to get always (#4)

Do you think you can share a dataset and a configuration to reproduce this?

Thanks

[amoorthaemer]

Hi @maggiolo00

Sure ...

config.zip

Dataset is as described in previous posts... So nothing facy

Cheers

Bert

[rrmerugu]

@wolf4ood I'm facing the same issue, i get this temporary RID when created a new vertex. But how do i get the actual id of the created vertex?