It appears this problem has not been solved and I would like to propose a
change to the ClassMolder class solves the problem for us.
Just to re-iterate the problem:
When your try to attach an existing independent object to a new object one
of two things happen:
if autostore is false: the FK in the database which refers to the existing
object is null
if autostore is true: a copy of the existing object is created with a new
key and attached to the new object
Proposed Solution:
If Autostore is true:
Check if object to be attached is in transaction and do nothing
If object to be attached is not in transaction try loading to bring it into
the transaction
If object can't be loaded (i.e. new) then mark it for creation
Changes to ClassMolder:
} else if ( tx.isAutoStore() )
{
// Check if object is available in transaction, if not then we need to
check if the object is persistent
// outside the transaction. If not persistent outside the transaction
then lets create it
if ( !tx.isRecorded( o ) )
{
TransactionContext.ObjectEntry entry;
Object identity = fieldClassMolder.getActualIdentity( tx, o );
if( identity == null )
{
tx.markCreate( fieldEngine, fieldClassMolder, o, null );
if ( !_fhs[i].isStored() && fieldClassMolder._isKeyGenUsed )
{
updateCache = true;
}
}
else
{
tx.load( fieldEngine, fieldClassMolder,identity,o,
AccessMode.Shared);
}
}
}
Any comments?
Regards
David J Snowsill
Principal Consultant
Calibre Financial Technology
[EMAIL PROTECTED]
Office: (61-2) 9212 0527
Mobile: 0403 091 468
----- Original Message -----
From: "Oleg Nitz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 12:11 AM
Subject: Re: [castor-dev] 1:N relationship: No FK being populated
> Hi Florian,
>
> This is a known issue, it is in our todo list.
>
> Oleg
>
> florian ramillien wrote:
> > Oleg Nitz a �crit :
> >>
> >> One more thing: are you setting references to A in B?
> >> I mean that
> >> a.getCol().add(b)
> >> is not enough, you should also call
> >> b.setFoid(a)
> >>
> > Thanks, It's the solution for my problem.
>
> > But why 'b' must have a relation to 'a' ?
> > In fact, with just the relation 'a->b' (1:n) it's can work.
> > If I consider this examples:
>
> > ** MAIN **
> > db.begin();
> > A a = db.load(A, id);
> > B b = new B();
> > a.getCol().add(b);
> > db.commit();
>
> > ** CLASS **
> > Class A {
> > String _id;
> > Collection _col;
> > }
>
> > Class B {
> > String _id;
> > }
>
> > **MAPPING**
> > <class A>
> > <field name="id">...</field>
> > <field name="col" type="B" collection="collection">
> > <sql many-key="a" />
> > </field>
> > </class>
>
> > <class B depends="A">
> > <field name="id">...</field>
> > </class>
>
> > **TABLE**
> > table A (
> > id varchar(100)
> > )
>
> > table B (
> > id varchar(10),
> > a varchar(10)
> > )
>
> > While I don't stop castor. After the execution of MAIN, if I reload 'a'
> > I can use the collection normally. But if I restart castor (ie: clear
> > castor cache) It's don't work because the relation has not persisted in
> > DB.
>
> > Why the persistance of this relation work in castor cache but not in DB
> > ?
>
> > The workaround is to define a second relation 'b->a'.
>
> > Thanks,
> > Florian.
>
> > -----------------------------------------------------------
> > If you wish to unsubscribe from this mailing, send mail to
> > [EMAIL PROTECTED] with a subject of:
> > unsubscribe castor-dev
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
