hi alan, it works with CircleTest after settin oneId and twoId to nullable=false. i'll do additional tests with your patch, i'm looking for a way to do only one insert instead of insert and update.
jakob ----- Original Message ----- From: "Jakob Braeuchi" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Thursday, December 19, 2002 8:57 PM Subject: Re: Referential Integrity Constraints > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
