Re: Interesting (failing) scenario of FKs/PKs in PB

[V.B. Skrypnyk]

Hi Armin,

I can only see 2 slight variances from my case:
1. My class doesn't have an autoincrement primary key
2. The reference is set from an object that already exists (it's not saved
in the same transaction)

I don't know if these variances are material. Does the test pass? (I can't
seem to compile the
project, there seem to be some problems with the StatementManager)

--Bill.


----- Original Message -----
From: "Armin Waibel" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 12, 2003 10:46 AM
Subject: Re: Interesting (failing) scenario of FKs/PKs in PB


> Hi Christian, Bill
>
> I currently add a new test case to demonstrate
> the described behaviour.
> Could you check if I hit the bull's eye.
> See ReferenceTest#testRepositoryFKStore
>
> regards,
> Armin
>
> ----- Original Message -----
> From: "Malinescu, Cristian" <[EMAIL PROTECTED]>
> To: "'OJB Users List'" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 12, 2003 6:15 PM
> Subject: RE: Interesting (failing) scenario of FKs/PKs in PB
>
>
> Hi
> Yes, I succeeded to this behaviour but only for Oracle, for MySQL was
> going
> OK,
> and for my typical situation I needed only one PK, no FK.
> This was strange for me, and I posted one email on this theme last week,
> but
> till
> now no remark/comment. I'm using the PB basic API.
> regards,
> Cristian
>
> -----Original Message-----
> From: V.B. Skrypnyk [mailto:[EMAIL PROTECTED]
> Sent: Mittwoch, 12. März 2003 18:02
> To: OJB Users List
> Subject: Re: Interesting (failing) scenario of FKs/PKs in PB
>
>
> Has anyone else encountered this problem?
>
> --Bill.
>
> > Hi,
> >
> > The following fails to be stored by PersistenceBroker:
> >
> > I have a class ACL which has two primary keys: objectId and userFK,
> and
> > userFK is also a foreign key tied to a reference of type User. If I do
> this:
> >
> > persistentBroker.beginTransaction();
> > ACL acl = new ACL();
> > acl.setObjectId( 100 );
> > acl.setUser( currentUser );
> > persistentBroker.store(acl);
> > persistentBroker.commitTransaction();
> >
> > Acl will not be saved. The reason seems to be because in the
> storeToDb()
> > method of the PersistentBroker, there first comes an assertion of the
> > PrimaryKeys and afterwards comes the assignment of all the foreign
> keys.
> In
> > the scenario above the assertion of the primary keys will fail,
> because
> the
> > userFK has not been assigned yet, so we have an incomplete set of
> primary
> > keys. This does work with the ODMG layer, probably because of a
> different
> > sequence of events during the storing of the object.
> >
> > I wonder if there should be a check whether a primary key is shared by
> the
> > foreign key and allow that assignment before the assertion of the
> primary
> > keys is performed. Any ideas?
> >
> > Cheers,
> > --Bill.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]