BUG: insert select edge creates invalid TO references

[marktshaw]

OrientDB Version: 2.x

Java Version: n/a

OS: n/a

Expected behavior

insert-select correctly copies all of the edges

Actual behavior

insert-select generates invalid edge meta-data

Steps to reproduce

I suspect this is a serious bug and is raising doubts about how OrientDB manages the integrity of the graphs data during various DML operations. How can an Edge have multiple TOs?

The below outlines a simple operation that is using 'insert into select' to copy a Vertex. Initial State

{ "result": [ { "@type": "d", "@rid": "#-2:1", "@version": 0, "rid": "#133:46", "version": 1, "class": "RuleSet", "out_HasRule": [ "#80:32" ], "@fieldTypes": "rid=x,out_HasRule=g" }, { "@type": "d", "@rid": "#-2:2", "@version": 0, "rid": "#130:39", "version": 1, "class": "Rule", "in_HasRule": [ "#80:32" ], "@fieldTypes": "rid=x,in_HasRule=g" } ], "notification": "Query executed in 0.213 sec. Returned 2 record(s)" }

If I execute the following, bad edge data is created. Notice that #80:32 is the IN for more than one Vertex.

insert into Rule from select * from #130:39;

'insert into Rule from select * from #130:39;'

{ "result": [ { "@type": "d", "@rid": "#-2:1", "@version": 0, "rid": "#133:46", "version": 1, "class": "RuleSet", "out_HasRule": [ "#80:32" ], "@fieldTypes": "rid=x,out_HasRule=g" }, { "@type": "d", "@rid": "#-2:2", "@version": 0, "rid": "#131:38", "version": 1, "class": "Rule", "in_HasRule": [ "#80:32" ], "@fieldTypes": "rid=x,in_HasRule=g" }, { "@type": "d", "@rid": "#-2:3", "@version": 0, "rid": "#130:39", "version": 1, "class": "Rule", "in_HasRule": [ "#80:32" ], "@fieldTypes": "rid=x,in_HasRule=g" } ], "notification": "Query executed in 0.151 sec. Returned 3 record(s)"}

@luigidellaquila

Stack Overflow - https://stackoverflow.com/questions/46781586/bug-insert-select-edge-creates-invalid-to-references

[luigidellaquila]

Hi @marktshaw

Thank you very much, I'll address it asap.

Luigi

[luigidellaquila]

Hi @marktshaw

I just pushed a fix for this on branch 2.2.x, it will be released with v 2.2.30

Now I'm porting the fix to develop branch (3.0)

Thanks

Luigi

[marktshaw]

Fantastic work Luigi. Is there an ETA for 2.2.30?

[luigidellaquila]

Not yet, but it should be a matter of a few days, a couple of weeks at most

Thanks

Luigi