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]>
PersistenceBrokerImpl.diff
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
