We are using this now and for us it works great. We had the same issue as Mike.
So I requested to have this stuff moved to public api: https://github.com/orientechnologies/orientdb/issues/3857 Op donderdag 3 oktober 2013 10:05:56 UTC+2 schreef Andrey Lomakin: > > Hi Mike, > We also have following event > com.orientechnologies.orient.core.db.record.ORecordElement#onBeforeIdentityChanged > > and > com.orientechnologies.orient.core.db.record.ORecordElement#onAfterIdentityChanged > > may be this will help you ? > It is internal now but we can verify whether it can be part of public API. > > > On Mon, Sep 30, 2013 at 5:18 PM, <[email protected] <javascript:>> wrote: > >> I don't think that would help us, though that's probably about the best >> we could do with the current RID system. Our transaction scope logic is >> separate from POJO creation, and it would be too much of a hack I think to >> try to update the POJOs with current ids after a commit. >> >> >> On Friday, September 20, 2013 11:27:50 PM UTC-5, Andrey Lomakin wrote: >> >>> Hi Mike, >>> If we manage to return map between temporary and new rids as result of >>> TX commit will it solve your problem ? >>> >>> P.S. We are planing to fix rid reuse in short term. >>> >>> >>> On Wed, Sep 18, 2013 at 7:29 PM, <[email protected]> wrote: >>> >>>> Forgot to add. >>>> >>>> I'm guessing that statement refers mainly to using a primary key as a >>>> unique row reference in an RDBS, vs. a key for a POJO. So I'm guessing the >>>> recommendation is to create a separate key field that is indexed, but that >>>> would be considered more a domain key and not a primary key. >>>> >>>> >>>> On Wednesday, September 18, 2013 11:10:54 AM UTC-5, [email protected] >>>> wrote: >>>>> >>>>> We are running into an issue trying to use RIDs as primary keys for >>>>> our objects. Our transaction boundary is in our service layer and our >>>>> DAOs >>>>> return POJOs with RIDs as their primary key. The problem is that inserted >>>>> documents get a temporary id until they are committed, but we create our >>>>> POJOs while still in a transaction, so they get the temporary id instead >>>>> of >>>>> the actual id. >>>>> >>>>> How have other people solved this? We could do some sort of cache of >>>>> POJOs that we update at commit time, but that is quite a hack and seems >>>>> brittle and hard to maintain. We don't want to use ORecordID as the >>>>> primary >>>>> key (if that would even work) as that will be sent all over the >>>>> application >>>>> then. We are left with creating some sort of id generator and creating a >>>>> primary key field, which is something the documentation says we don't >>>>> have >>>>> to do ("You can access a record directly by its RecordID. For this reason >>>>> you don't need to create a field as a primary key like in a Relational >>>>> DBMS."). >>>>> >>>> -- >>>> >>>> --- >>>> 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 [email protected]. >>>> >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Andrey Lomakin. >>> >>> Orient Technologies >>> the Company behind OrientDB >>> >>> -- >> >> --- >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Best regards, > Andrey Lomakin. > > Orient Technologies > the Company behind OrientDB > > -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
