Transactions do not update RID post commit when RID is nested

[loadedlux]

Hi,

I am trying to use Orient Transactions and I am running into issues.  I have provided a test case below.  The code and example below may seem arbitrary but it is a part of a scala DAO implementation that includes transactions. 

I am trying to:

1) start a transaction

2) create a first and second ODocument

3) store the temporary RID value of the first ODocument in a "nested" field of the second ODocument

4) commit the transaction and have the temporary RID stored in the second ODocument updated to the final RID value 

In the example below.. 

there is a Person Class and an Event Class. Event Class has an "admin" field that is collection of a wrapper class for RIDs. The example below displays that when the RID is inside of the wrapper class it will not be updated to reflect the commit.

import com.orientechnologies.orient.core.record.impl.ODocument;

import com.orientechnologies.orient.core.storage.OStorage;

import com.orientechnologies.orient.core.tx.OTransaction.TXTYPE;

import com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx;

import com.orientechnologies.orient.core.id.ORID;

import com.orientechnologies.orient.core.metadata.schema.OClass;

import java.util.List;

import java.util.ArrayList;

class Main{ 

  public static void main (String [] args) { 

      ODatabaseDocumentTx db = new ODatabaseDocumentTx("memory:test");

      db.create(); 

      

      OClass person = db.getMetadata().getSchema().createClass("Person");

      OClass event = db.getMetadata().getSchema().createClass("Event");

      OClass eventjson = db.getMetadata().getSchema().createClass("Event_JSON");

      

      db.begin( TXTYPE.OPTIMISTIC );

      ODocument doc = new ODocument("Person"); 

      doc.field("name","Sunil");

      doc.save();

      ORID adminID = doc.getIdentity();

      List<ORID> adminList = new ArrayList<ORID>();

      adminList.add(adminID);

      

      ODocument doc2 = new ODocument("Event"); 

      doc2.field("event_name","world cup 2014").field("admin",adminList);

      doc2.save();

      

      ODocument doc3 = new ODocument("Event_JSON");

      doc3.fromJSON("{\"event_name\":\"world cup 2018\",\"admin\":[{\"typehint\":\"oID\",\"id\":\""+ adminID + "\"}]}");

      doc3.save();

      

      db.commit();

      

      for (ODocument o : db.browseClass("Event")) {

          System.out.println(o.toJSON());

      }

      

      for (ODocument o : db.browseClass("Person")) {

          System.out.println(o.toJSON());

      }

      

      //Output will include the temp id and not the id assigned after the transaction is committed

      for (ODocument o : db.browseClass("Event_JSON")) {

          System.out.println(o.toJSON());

      }

      

      db. close ( ) ; 

  }  

}

[loadedlux]

FYI I am using OrientDB Server v1.7-rc1 

[loadedlux]

I have attached a clearer example ...

[Andrey Lomakin]

HI,

Do not store temporary rids, store documents.

They will be converted to the links automatically during commit.

Is it good enough for you ?

And why you do not use rc2 version ?

On Mon, Apr 7, 2014 at 5:46 AM, loadedlux <id.publ...@gmail.com> wrote:

I have attached a clearer example ...

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,
Andrey Lomakin.

Orient Technologies
the Company behind OrientDB

[I D]

Unfortunately that will not work.  My test is an abstraction of my problem but does not communicate my project design.  I fully understand if this considered a personal issue, but would greatly appreciate a point in the direction of the orientdb-core code I might have to fork.

My implementation stores links with ORID wrapper classes. For example:

case class Person(name: String, friends: List[ORIDWrapper]).  Thus, if Adam is friends with Bob, Adam's friends field will contain an ORIDWrapper object that wraps Bob's @rid. 

My guess is that the orient code only looks for ORID or Collections of ORIDs when updating temporary IDs.  I have found that to be the case with the traverse function (i.e., it will not traverse a string or orid format if its in a wrapper). 

I plan on moving to rc2.. just wanted to add a transaction method to this makeshift orientDB Scala DAO first.

--

---
You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/kAmkR6DL8Fk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.

[Andrey Lomakin]

We have fixed issue , which is exactly the same as you described .
So could you try rc2 it should be fixed there especially if you use approach I described .

07 апр. 2014 г. 22:41 пользователь "I D" <id.publ...@gmail.com> написал:

[I D]

I am not able to use the approach you described. However, The issue persist with RC2 when I store the id.

 

[Andrey Lomakin]

Hi,

But I suggested to use document instance but not the id.

Any way how do you store id could you provide code which I can start and check that approach does not work.

Could you provide working code because pseudo code may work and we will spend time for nothing.

On Tue, Apr 8, 2014 at 2:21 AM, I D <id.publ...@gmail.com> wrote:

I am not able to use the approach you described. However, The issue persist with RC2 when I store the id.

 

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[I D]

Is it ok if I provide code in scala? I know in the past that luca has
asked for java test.

> You received this message because you are subscribed to a topic in the
> Google Groups "OrientDB" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/orient-database/kAmkR6DL8Fk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Andrey Lomakin]

I do not know Scala.

Sorry. So Java would be preferable.

[I D]

Please find attached java code that illustrates how my scala performs.

The JSON string

"{\"event_name\":\"world cup 2018\",\"admin\":[{\"typehint\":\"oID\",\"id\":\""
+ adminID + "\"}]}"

is the equivalent to
case class Event(event_name:String, admin:Set[oID])
case class oID(typehint:String,id:String)

we store an id in a oID wrapper class .. the id field is the @rid
value. However, it appears that even if we just stored the @rid
without a wrapper class the issue would persist.

In short, My project code includes a save method that takes a Scala
Object as a parameter and uses a JSON library to produce a JSON
string from the Scala object. I then use the fromJSON method to create
an ODocument and save the ODocument. I did not include this json step
in the java code I provided.

Thank you very much. I truly appreciate your help and patience.

[I D]

Hi Andrey,

Have you had an opportunity to check out the test code?

Further, I have question about the toJSON and fromJSON methods. Are
they suppose to be inverse functions. In view of the fetch plan
feature,

toJSON might return a link between a first document and a second
document represented merely as an rid as in the admin field below:

{"@type":"d","@rid":"#10:0","@version":0,"@class":"Event","event_name":"world
cup 2014","admin":["#9:0"]}

However, providing this same string as a parameter to the fromJSON
will not create the same relationship.

Would it be possible to have attribute type that could be used to
indicate that rids are being provided for the purpose of creating a
reference/link to document having a provided @rid ?

so instead of

{
"@type" : "d"
"Name" : "Test",
"Data" : { "@type": "d",
"value": 0 },
"@class" : "SimpleEntity"
}

it could be ..

{
"@type" : "d"
"Name" : "Test",
"Data" : { "@type": "l",
"@rid": #12:3" },
"@class" : "SimpleEntity"
}



..

As you suggested, I looked into storing the document but it appears it
would only work if the inner document is being created simultaneously
which would not allow me to create a reference to a pre-existing
document. Providing an existing document as an inner object creates a
new document and could lead to circular references..

[loadedlux]

should i create an issue on github?

>> >> email to orient-database+unsubscribe@googlegroups.com.

>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Andrey Lomakin.
>> >
>> > Orient Technologies
>> > the Company behind OrientDB
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "OrientDB" group.
>> > To unsubscribe from this topic, visit
>> >
>> > https://groups.google.com/d/topic/orient-database/kAmkR6DL8Fk/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to

>> > orient-database+unsubscribe@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OrientDB" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to orient-database+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Best regards,
> Andrey Lomakin.
>
> Orient Technologies
> the Company behind OrientDB
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "OrientDB" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/orient-database/kAmkR6DL8Fk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> orient-database+unsubscribe@googlegroups.com.

[loadedlux]

Hi Andrey,

Your suggestion to store the document does not work as expected when the inner document is created within a transaction.  I have provided a test example attached to this post.  Please note that when a document is created within a transaction (i.e., eveDOC) and then provided as an inner document inside the same transaction, there are two copies of the document saved to the DB upon the commit instead of 1.

Thanks in advance.