[V3] Results of two transactions not as expected

[pvalsecc]

OrientDB Version: 3.0.0m2

Java Version: The one from the docker image

OS: The official docker image

Expected behavior

Just after a transaction creating two instances of V and one instance of E linking them together, I get, when doing a SELECT FROM V to see the correct content of my 2 Vs and my E in the result.
If I use another transaction to delete one of the Vs and update the other (one of the fields with a different value), when I do a select I expect to get my only V, with its fields.

Actual behavior

OrientDB v3.0.0m2 returns an empty V record (no field at all) after my second transaction when v2.2.24 was doing fine. If I check its content with studio, I see the same problem.

Steps to reproduce

I'm using a home made Erlang client library, so I'll start by giving you pseudo code of what I'm doing:

• Create an empty database
• Connect to it (the rest of the operations is done with this single connection)
• In a single connection, create 2 instance of V ({toto: 42, tutu= 'tutu'} and {x: 4.5}) and one instance of E linking them together
• Do a command (type "q"): SELECT FROM V
• Check the results match what I expect
• In another transaction, delete one of the 2 V and update the other ({toto: 43, tutu= 'tutu'})
• Do a command (type "q"): SELECT FROM V
• Check the results match what I expect

Here is a dump of what happens on the socket:

• The TX_COMMIT:
  • Send: 0x3C0000001F0000007B00000000047465737400FFFFFFFFFFFFFFFFFFFF0000015E960DD7D6010004726F6F74002500174F5265636F726453657269616C697A657242696E61727900164F7269656E7444422045726C616E6720436C69656E740003302E318920A36B98D02120F454C05928F419079AEF6C765E7C0460AC5D9EBC4591A5ED00000001010103FFFFFFFFFFFFFFFFFFFE6400000047000256086F75745F000000221608746F746F0000004101087475747500000042070003647DECE703DE4779334122E474B29DC200000001FFFFFFFFFFFFFFFFFFFC5408747574750103FFFFFFFFFFFFFFFFFFFD640000003B00025606696E5F000000141602780000003305000398E21317D09B48701D42CE048F1B503600000001FFFFFFFFFFFFFFFFFFFC40120000000000000103FFFFFFFFFFFFFFFFFFFC640000001900024504696E000000150D066F7574000000170D00010301050000000003000000
  • Receive: 0x000000001F0000000000000003FFFFFFFFFFFFFFFFFFFD000A0000000000000000FFFFFFFFFFFFFFFFFFFC00110000000000000000FFFFFFFFFFFFFFFFFFFE0009000000000000000000000003000A0000000000000000000000010009000000000000000000000001001100000000000000000000000100000000
• The COMMAND:
  • Send: 0x290000001F0000007B00000000047465737400FFFFFFFFFFFFFFFFFFFF0000015E960DD7D6010004726F6F74002500174F5265636F726453657269616C697A657242696E61727900164F7269656E7444422045726C616E6720436C69656E740003302E318920A36B98D02120F454C05928F419079AEF6C765E7C0460AC5D9EBC4591A5ED730000002500000001710000000D73656C6563742066726F6D2056FFFFFFFF000000032A3A3100000000
  • Receive: 0x000000001F000000006C00000002000064000900000000000000000000000100000037000256086F75745F000000221608746F746F00000031010874757475000000320700010000000100110000000000000000540874757475000064000A0000000000000000000000010000002B00025606696E5F0000001416027800000023050001000000010011000000000000000040120000000000000200006400110000000000000000000000010000001900024504696E000000150D066F7574000000170D001200140000
• The second TX_COMMAND:
  • Send: 0x3C0000001F0000007B00000000047465737400FFFFFFFFFFFFFFFFFFFF0000015E960DD7D6010004726F6F74002500174F5265636F726453657269616C697A657242696E61727900164F7269656E7444422045726C616E6720436C69656E740003302E318920A36B98D02120F454C05928F419079AEF6C765E7C0460AC5D9EBC4591A5ED0000000201010100090000000000000000640000000100000037000256086F75745F000000221608746F746F00000031010874757475000000320700010000000100110000000000000000560874757475010102000A000000000000000064000000010000000003000000
  • Receive: 0x000000001F000000000000000000000001000900000000000000000000000200000000
• The second COMMAND:
  • Send: 0x290000001F0000007B00000000047465737400FFFFFFFFFFFFFFFFFFFF0000015E960DD7D6010004726F6F74002500174F5265636F726453657269616C697A657242696E61727900164F7269656E7444422045726C616E6720436C69656E740003302E318920A36B98D02120F454C05928F419079AEF6C765E7C0460AC5D9EBC4591A5ED730000002500000001710000000D73656C6563742066726F6D2056FFFFFFFF000000032A3A3100000000
  • Receive: 0x000000001F000000006C00000001000064000900000000000000000000000200000004000256000

As you can see, the only remaining V has just an empty record, no field.

Another difference I have with V2 is the disappearance of the E in 3.0.0m2 when 2.2.24 was leaving it undeleted. I was expecting OrientDB to delete the edges connected to deleted vertices. So, in that regard, V3 is behaving better. If only it was not nuking all my fields.

[pvalsecc]

OrientDB logs available there:
https://gist.github.com/pvalsecc/2969f56dfce1aa92b35725ad3b40eef5

[tglman]

Hi @pvalsecc,

Could you try the last snapshot? we fixed a few issue in the remote transactions recently.

Regards

[pvalsecc]

Latest docker image is a 2.2.24. So, unless you have an image with the latest snapshot, I cannot really test it easilly. I guess I'll wait next milestone.

[pvalsecc]

I've found the time to compile the develop branch.
OK, this very issue is fixed and my testcase passes. I have other testcases failing, though. I'll create other issues for that. Thanks.

[pvalsecc]

The two other bugs:

• live select seems broken in v3 (develop) #7761
• Adding an edge in a second transaction doesn't work #7762