REST embeds edge into record

[andreyvk]

OrientDB Version: 3.0.14

Java Version: 1.8

Hi,

There's a strange behavior in REST protocol.

The query issued looks like this:

create edge has_a from #84:169544 to #34:32951 content {"type":"Company","billing":true}

Problem doesnt happen always, but in many cases it looks like the edge is embedded in to "out_has_a" attribute like so (all irrelevant attributes are removed from document sample below):

{
    "out_has_a": [
        "#130:10713663", 
        {"in":"#34:34274","type":"Company","out":"#84:169275","billing":true,"@class":"has_a","@version":0}
    ]
}

Issue is not reproducable from Studio or console. I've spent hours trying to figure out what's causing it, but still couldnt figure out why. I've also tried not using content in the command and used set type='Company', billing = true instead, but the problem persists. Hopefully this information is enough to find the bug.

I'll keep this thread updated when I find more.

[andreyvk]

Hi @luigidellaquila,

I've found how to reproduce this. The problem happens after record update request, whether full or partial:

First prepare some classes and records:

# cluster ID will be 260
create class MyClass extends V

# clusted ID will be 261
create class linked_to extends E

insert into MyClass content {"a": 1}
insert into MyClass content {"a": 1}

Then using REST (not URL encoded for making it readable):

1. POST http://localhost:24800/command/nsdev/sql/create edge linked_to from #260:0 to #260:1

2. PUT http://localhost:24800/document/nsdev/#260:0?updateMode=full
{"@version":2,"@class":"MyClass","a":2,"out_linked_to":["#261:0"]}

3. POST http://localhost:24800/command/nsdev/sql/delete edge #261:0

4. POST http://localhost:24800/command/nsdev/sql/create edge linked_to from #260:0 to #260:1

Below are the screenshots from the REST client I used to test and final result in the Studio:

[luigidellaquila]

Hi @andreyvk

Thank you very much, it helps a lot. I'll look into it ASAP

Thanks

Luigi

[andreyvk]

hi @luigidellaquila,

Have you been able to reproduce this problem?

[luigidellaquila]

Hi @andreyvk

Sorry, not yet...

Luigi

[andreyvk]

Hi @luigidellaquila,

Is this going to be checked on before the release of 3.0.16?

[usef911]

Hi @luigidellaquila
Has there been any progress on this at all?

[luigidellaquila]

Hi @andreyvk

I managed to reproduce the problem and I think I have a high level idea of what's going on.
Probably the PUT operation changes the type of the out_*, in_* collections, from LINKBAG to EMBEDDEDLIST, so when you do the CREATE EDGE the document is persisted as embedded.
I'm still verifying this hypothesis, I'll keep you updated

Thanks

Luigi

[andreyvk]

hi @luigidellaquila,

Eagerly looking forward for the fix, because it's probably the only thing that's keeping us from moving to 3.0.x fully

[andreyvk]

@luigidellaquila hi,

Any luck with this issue?

[usef911]

Hi @luigidellaquila
Any updates on this? This bug essentially makes the REST API unusable.
Thanks

[andreyvk]

Hi @luigidellaquila ,

Is there any chance this issue gets fixed at any point of time?

I just remember our CEO had a chat with @lvca previously regarding Orient's PHP support for 3.0 version. Luca himself suggested moving to REST protocol, because it was supposed to be the key solution to all our problems with PhpOrient. However, if REST protocol doesnt work properly, then situation runs into a deadlock.

Would you please suggest anything concrete on this problem, please? We are running out of time trying to keep our project running this database.

[luigidellaquila]

Hi @andreyvk

From our analysis, this issue is definitely not of easy solution. The problem here is that, in a schemaless db, it's hard to do inference on JSON documents and how a simple [#xx:xx, #yy:yy] has to be treated (eg. as a list, a set or a linkbag).

I cannot give you an ETA now, so my suggestion for the short term is (if you have a chance) to use SQL instead of PUT/POST

Thanks

Luigi

[andreyvk]

Hi,

Ok, that's fine with schemaless. But our db is schemaful. Why wouldnt the functionality work then?

A.

[usef911]

Hi @luigidellaquila
Has there been any progress on this issue with the REST API?
Thanks
Y