hi alan, thanks for your contribution, i'll check it asap. imo the infinite loop is a known problem when running without cache.
jakob ----- Original Message ----- From: "Olmanson, Alan" <[EMAIL PROTECTED]> To: "'OJB Users List'" <[EMAIL PROTECTED]> Sent: Friday, January 03, 2003 6:57 PM Subject: RE: Referential Integrity Constraints > Hi Jakob, > > I have an idea. I've attached some code, which passes all the broker tests > except MtoNMapping.testDeleteUnidirectional. This test fails because in the > storeCollections methods I've moved deleteMtoNImplementor after the proxy > check, and the test does a clear on the MtoN collection which makes it look > like it's not loaded. Should the test maybe be doing a removeAll()? I've > moved this since I was getting a infinite loop if the MtoN was bidirectional > (with no cache) each side would materialize the other. > > It also fails the odmg test OneToManyTest.testUpdateWithProxy, however I > don't know that much about ODMG to understand what may be wrong there. > > What I've done is wrap each object we are going to store with a Storage > object. This object has all the store functions, and the current state of > the objects storage. This allow for the state to change while we are storing > the object, so if the object is being inserted and we come to an object that > needs the object in the database, the object is quickly added by the > assertInserted method which only inserts the required fields. Another query > later updates the object with the non-required fields. So we still have to > do two SQL calls but only when it is necessary (at least that's the idea). > > Hopefully the code isn't to hard to understand, so you can at least get the > idea. > > I should also note that I originally worked on this in the 0.9.8 release > version, and have here put it into the 1.103 CVS version. > > Alan > > -----Original Message----- > From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 02, 2003 3:52 AM > To: OJB Users List > Subject: Re: Referential Integrity Constraints > > > hi alan, > > imo the solution to this problem is not as easy as i thought. storing the > object before storing it's references works for the testcase you provided, > but what if the user stores the child first. > i think we need a way to automatically decide the order of storing objects ! > this is issue 435 on the todo list. > > any ideas > jakob > > ----- Original Message ----- > From: "Jakob Braeuchi" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]> > Sent: Thursday, December 19, 2002 10:32 PM > Subject: Re: Referential Integrity Constraints > > > > 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]> > > > > > -- > 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]>
