Hi ,
Following advice of Armin, I changed in repository_database.xml
eager-release="true"
batch-mode="true"
to
eager-release="false"
batch-mode="false"
and now insert works for my Oracle 8 instance.
Regards,
Cristian
-----Original Message-----
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 12. März 2003 23:59
To: OJB Users List
Subject: Re: Interesting (failing) scenario of FKs/PKs in PB
----- Original Message -----
From: "V.B. Skrypnyk" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>; "Armin Waibel"
<[EMAIL PROTECTED]>
Sent: Wednesday, March 12, 2003 11:01 PM
Subject: Re: Interesting (failing) scenario of FKs/PKs in PB
> 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...
>
sounds good (means I don't have a clue ;-)).
This part of OJB is definitely not my special subject.
If you find a solution I will check in your code.
Test is in, let the gurus make the work ;-)
regards,
Armin
> --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]
>
>
>
---------------------------------------------------------------------
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]
