we're seeing the problem with Castor 0.9.2. Should 0.9.2 have the new algorithm? I'm not sure the algorithm you mention will always work. We have the following set of relationships between our classes:
Subscription depends on Header which depends on User
DataSet depends on User
This all looks well and good so far but a problem arises because Subscription also contains a reference to DataSet. Would your algorithm ensure that DataSet's are created before Header's even though they both depend on User? If Header's are created first then their Subscription's end up with a reference to a non-existent DataSet and referential integrity is broken.
Here are the relationships again as they appear in our mapping file:
<class name="User" identity="key">
<map-to table="TEST.USER"/>
<field name="key" type="string" direct="true">
<sql name="USER_ID" type="varchar"/>
</field>
<field name="dataSets" type="DataSet" collection="arraylist">
<sql many-key="USER_ID"/>
</field>
<field name="headers" type="Header" collection="arraylist">
<sql many-key="USER_ID"/>
</field>
</class>
<class name="Header" identity="key" depends="User">
<map-to table="TEST.HEADER"/>
<field name="key" type="string">
<sql name="HEADER_ID" type="varchar"/>
</field>
<field name="subscriptions" type="Subscription"
collection="arraylist">
<sql many-key="HEADER_ID"/>
</field>
</class>
<class name="Subscription" identity="key" depends="Header">
<map-to table="TEST.SUBSCRIPTION"/>
<field name="key" type="string">
<sql name="SUBSCRIPTION_ID" type="varchar"/>
</field>
<field name="header" type="Header">
<sql name="HEADER_ID"/>
</field>
<field name="dataSet" type="DataSet">
<sql name="DATA_SET_ID"/>
</field>
</class>
<class name="DataSet" identity="key" depends="User">
<map-to table="TEST.DATA_SET"/>
<field name="key" type="string">
<sql name="DATA_SET_ID" type="varchar"/>
</field>
</class>
Obviously the reverse order is required for deletion (i.e. Header's would be deleted before DataSet's). Thanks for your help!
Max
Thomas Yip wrote:
Thank Max,For creation, "educated guesses" was just implemented for a few days. The
current algorithm is that any object's table T, has foreign key and the
foreign key is referring to a key-generated object R, then R will be created
before T, providing T is not equal to R.I will see if this algorithm is significant or not. If it are not, I would
consider your suggestion.Yes, I guess we would do the same things to deletion in the new code.
Thomas
-----Original Message-----
>From: Max Foxell [mailto:[EMAIL PROTECTED]]
>Sent: Friday, August 03, 2001 10:59 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Feature request: enhance rules governing dependent
object creation/deletion
>
>Hi,
>
>I've been using Castor for a few months now and have found it extremely
>useful ;-). I noticed recently that there are plans to refactor the JDO
>portion of Castor and I thought this would be a good time to ask for a
>feature request. One of the problems I've found with Castor is that
>there isn't enough control over the order of creation and deletion of
>dependent objects. Without this control referential integrity can be
>broken. As a work around we have to have two sets of configuration files
>(one used for adding stuff to the database and one for removing stuff).
>One solution would be to specify the creation/deletion order in the
>mapping file. If the code were especially smart Castor could make
>educated guesses at the appropriate order automatically by examining the
>references in the mapping file and looking at the database meta data.
>Hope you manage to fit this into your plans :)
>
>Thanks,
> Max Foxell
>
>-----------------------------------------------------------
>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
