hi alan, thanks for the patch. it passes all official ojb testcases without problem. but the circle test fails although i store OneTable instead of TwoTable. the problem is the insertion of the Child, it's twoId is still 0 whil it's oneId is 1.
jakob ----- Original Message ----- From: "Olmanson, Alan" <[EMAIL PROTECTED]> To: "'OJB Users List'" <[EMAIL PROTECTED]> Sent: Thursday, December 19, 2002 8:01 PM Subject: RE: Referential Integrity Constraints > Jakob, > > Sure, here it is. There is one additional change, when it stores the > primary key references it also now stores any non-nullable references. > > Alan > > -----Original Message----- > From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 19, 2002 12:19 PM > To: OJB Users List > Subject: Re: Referential Integrity Constraints > > > hi alan, > > please send me the whole file, eclipse does not like the patch :( > > jakob > ----- Original Message ----- > From: "Olmanson, Alan" <[EMAIL PROTECTED]> > To: "'OJB Users List'" <[EMAIL PROTECTED]> > Sent: Wednesday, December 18, 2002 11:59 PM > Subject: RE: Referential Integrity Constraints > > > > Jakob, > > > > After trying some other things, your idea lead me in a direction that > > appears to work. > > > > The included CVS diff, is a patch that worked for our classes, however it > > doesn't work for the test case I sent earlier. (Since we use BigDecimals > as > > keys which can be null, and the test case uses ints which can not be > null.) > > > > What I did was moved the inserting of an object before its references > > (except for the references that affect the primary key), then assigned the > > reference keys and then did an update on the object, so it takes two > queries > > to insert an object. > > > > Does anyone see anything with this solution which would be a mistake? > > > > Alan > > > > > > -----Original Message----- > > From: Olmanson, Alan [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, December 17, 2002 4:48 PM > > To: 'OJB Users List' > > Subject: RE: Referential Integrity Constraints > > > > > > Jakob, > > > > If your solution is in the testcase, then for the simplified test case I > > provided that would probably work, however it is a simplified test case > and > > the real situation is more complicated and I don't think that will work. > > > > If you mean within the OJB store method, then it would fix this test case, > > however I'd assume it would brake others, where we are calling store on a > > child object. > > > > The problem is that a class has two required references (enforced by the > > database). > > > > A --> B > > | / > > v / > > C < > > > > The test case tries to store B. Storing B will first store the references > > which this case is A. A will store its reference (none),then itself (A), > > then its collections (C). C will store its references (B, however it is > > marked as stored already [which it isn't], so store is skipped), it then > > tries to store itself (C) which fails since B isn't in the database. > > > > So our current order of storing to the database if we call store(B) is A, > C > > (exception thrown no B) > > what we want to have happen is A, B, C > > If we stored the object before its references and collections we would > have: > > B, A, C. Which would work (unless the A --> B relationship is enforced.) > > > > So there needs to be is a way to wait to store an object (C) until after > all > > of its references are actually stored into the database. > > > > Alan > > > > -----Original Message----- > > From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, December 17, 2002 4:12 PM > > To: OJB Users List > > Subject: Re: Referential Integrity Constraints > > > > > > hi alan, > > > > thanks for your testcase. > > do you think we could solve the problem by storing A _before_ storing it's > > references and collections ? > > > > jakob > > > > ----- Original Message ----- > > From: "Olmanson, Alan" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, December 16, 2002 4:12 PM > > Subject: Referential Integrity Constraints > > > > > > > Hello, > > > > > > For our application we are using a database that has a lot of > referential > > > integrity constraints in it. And we have run into a situation in which > > OJB > > > is hitting one of them. > > > > > > The problems occurs when we are storing a graph of objects, using the > PB. > > > > > > A m<--1 B 1-->m C 1-->m D m<--1 A > > > > > > In the database the B and C's are already existing. We create a object > A > > > which is has a reference to B, for each C attached to B we create a > object > > D > > > which is also added to a collection on A. > > > > > > The problem arises when A is stored. First OJB marks A as being stored, > > > saves it references (B) which stores B's collections (C) which stores > C's > > > collections (D) which tries to stores its references (A) A is already > > marked > > > as stored (however it isn't in the database, since we are still storing > > its > > > references). When we try to store D we get a referential integrity error > > > because the record referenced in A by D doesn't exist. > > > > > > Is this a bug/oversight in the PB, or something we need to work around > in > > > our DB/code? > > > > > > Alan > > > > > > -- > > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > -------------------------------------------------------------------------- -- > ---- > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > ---------------------------------------------------------------------------- ---- > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
