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]>

Reply via email to