Michael,

let me try to address some of your questions, but not necessarily in order.

When you have a situation like this where there is a relationship netween two classes (B and C in your case), things
behave quite different from what you seem to be expecting. When you load an instance b of type B, Castor will load
the closure of what is declared in e.g. the mapping file. In your case, Castor will load instance b because of your load
() request, but within the same transaction it will load an instance c of type C as well because of the relationship
you've defined.

Let's have a look at a possible mapping file for this scenario:

<class type="somePackage.B" identity=id">

<map-to table="TABLE_B" />

<field name="id" type="integer">
<sql name="id" />
</field>

<!-- ***************** -->
<field name="C" type="somePackage.C" required="true">
<sql name="c_id" />
</field>
<!-- ***************** -->
</class>

<class type="somePackage.C" identity=id">

<map-to table="TABLE_C" />

<field name="id" type="integer">
<sql name="id" />
</field>

<field name="description" type="string">
<sql name="desc" type="varchar"/>
</field>

</class>

The field definition between <!-- ******** --> defines a unidirectional relationship between B and C in such a way that
each instance of B points to an instance of C. Because of the required="true", this is a compulsory relationship in
that each instance of B has to point to an instance of C.

I hope this helps.

Werner

On Mon, 10 Nov 2003 17:01:14 +0100, michael simons wrote:

>Hi,
>
>This might be a little off topic, but we have discussed it a lot here.
>
>How do You manage problems like the following:
>
>You have two objects b, c of two classes B, C where b references c. (b -> c)
>
>At the beginning b and c are persistent.
>You change b and commit the change. So now b and c are transient now.
>You change an attribute of b so you have to make b persitent because
>otherwise the change won't be written to the database. (right?) So you
>make it persistent.
>If you save b, the field of b referencing c will be set NULL because c is
>still transient, so we have to make it persistent too (right?)
>
>Well, but how do You detect which objects are to be made persistent? In the
>case of the object b it's obvious, but how do you detect that you have to
>re-load c?
>
>I hope that I described our problem enough so You can help us.
>
>Regards,
>Michael
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>




Reply via email to