Interestingly it fails silently, because after the assertion of primary keys the storeToDb() simply returns. Maybe foreign references should be expanded before the primary keys are asserted...
--Bill. ----- Original Message ----- From: "Armin Waibel" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, March 12, 2003 1:49 PM Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > The test fails because after commit none object > was persisted to database. > > regards, > Armin > > ----- Original Message ----- > From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]>; "Armin Waibel" > <[EMAIL PROTECTED]> > Sent: Wednesday, March 12, 2003 10:37 PM > Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > > > > 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] > > > > > > > > > --------------------------------------------------------------------- > 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]
