Thanks. Response is in red.
I'm suspecting a bug. Regards. On 3/5/06, Armin Waibel <[EMAIL PROTECTED]> wrote: > > Hi Bruno, > > whew! Sounds really complex, I try my best... > > The first problem is the bidirectional reference between P1, P2. To > establish the FK (e.g. in P1 from P2) the referenced object (P2) have to > be persistent (else the PK of P2 will be 'null' and OJB will set FK in > P2 'null' too). > In CircularTest you can find examples for handling bidirectional > references (with DB constraints) e.g. > CircularTest#testBidirectionalWithConstraint() > > http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?view=markup > > Say we only want to insert P1,P2. In this case you can do > > new P1 > new P2 > flush (now both PK values exist) > set ref P1 to P2 > set ref P2 to P1 > commit > > But there are other possibilities to store P1<-->P2 (see test-suite > examples) > > Generally the ordering used by OJB first try to insert the 1:1 > references of an object then the object itself and then the 1:n, m:n > references (if you don't like it, it's possible to disable OJB's > ordering). > > > > > Now, with the OJB 1.0.4, circular or 1:1 cross references shouldn't > > require flush(). > > This is not correct. It only mean that it is possible to handle > bidirectional references and the user should take a look in CircularTest > > http://db.apache.org/ojb/docu/guides/odmg-guide.html#Circular-+and+Bidirectional+References > > > > I don't known how it has been made, but i assume it works. > > So, i consider now that OJB can find the good order (and the back on > first > > object to put last reference), however we still continue to create, > > reference, unreference, delete with the DB sequence. > > > > But i'm going to try to give you an example, that worked before 1.0.4. > (with > > flush()) and do not any more. > > I think it worked "accidental". Before 1.0.4 when *not* using database > identity columns (like mysql supports) the PK's are created before the > object was stored to DB (create PK for P1 and P2, resolve references, > set FK, insert objects). > > > > > > -consider the circular pair of objects P1 and P2 (1:1 relation > > , cross-referenced) > > -consider now that we have a "M"aster object, that have a collection > > of "D"etails obects, themselves referencing an instance of P1. Let's > call > > master object M, and details objects D. > > - consider a last refrence relation between P1 and M (the master) > > > > So, all writing process is done like this (assume "new" is instanciating > and > > locking at the same time): > > > .... > > it's schematic but I believe there is all to explain. > > > > Our first problem was, that, after commit, P1 was not referencing M in > > database. I deduced that after a flush(), new locked objects (before > flush) > > can't reference new ones created before flush too (a second time). Humm, > > strange... we check all code : No apparent mistakes. Understand reference after have been made, and not in the database. It can be a bug for me. the reference is between 2 new instanciated and flushed object. We have tested many times, and can't understand at all. > > > Then, I found this about 1.0.4 releases notes [[OJB-18] - ODMG ordering > > problem with circular/bidirectional 1:1 references]. Well, OJB finds > the > > good order now and close the circular schema, fine. So we tried to > remove > > [flush #2] and process worked. > > > > After, i said to all my team to remove flush(). Everyone was happy ! And > > after [flush #1] was removed, process crashed with the FK constraints P2 > to > > P1 (you known, the circular pair) . It seems ODMG (without any flush) > does > > not find the good order to solve a "far" circular pair. I don't known > why at > > all. > > Sorry for the hassle. The explanation is given above. You should always > ask "when will the PK exist" -> after the object is inserted. So to set > the FK's of a P1<-->P2, P2 have to be persistent to assign the FK in P1 > and P1 have to be persistent to assign the FK in P2 -> impossible to > find a order. > E.g. new P1, P2, set both references and then lock P1 or P2, OJB will > only resolve one reference, e.g. commit call--> set FK in P2 (P1 PK is > 'null' --> FK 'null'), insert P2, set FK in P1 (PK of P1), insert P1. > > > > > Don't forget we have there a "double inside" circular reference (P1 & P2 > > inside M-D-P1 & P1-M). At first, i didn't think about resolve this > > construction without 2 flushes minimum. And now, i have only one! Sorry > for > > headache, but i'm lost too. > > > > Isn't it great? > > For example, the code below should work too (with one flush) > > > [tx.begin] > > - new M > > - loop of (D) > { new D (assume that mean add D to list/collection in M) > D references M (think this should work ,but maybe this have be done > after flush too) > new P1 , > D references P1 > new P2 , > flush() (now all PK of all object should exist) > P1 references P2 , > P2 references P1) > P1 references M > > } > > [tx.commit] > > > > > I have an enourmous doubt about the other processes that still have > flush > > steps and work on an equivalent part of model (double circular). > > Additional flush() calls should never cause problems. Flush only write > the current locked objects to DB. Things looks to be different in my case (with 2 flushes). The object (locked again after flush (why not)) seems to be ignored by transaction, as being already treated ! That is a little right (at flush). > > > Please, could you explain me the different ordering behaviours of ODMG? > > See above (when ordering is enabled, first 1:1, object itself...). If > you disable ordering the order of objects is determined by the lock > calls (when implicit locking is disabled too). > > > And > > when put a flush or not? > > I can't give a rule for using flush. For best performance use it only > when needed (each flush call perform the object detection/ordering). > > regards, > Armin > > > > > Thanks a lot. > > > > References : OJB 1.0.4, ObjectDefaultImpl, ODMG transactions with "same > > broker" queryObject methods (to possibly retrieve instanciated objects > > before commit ) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
