Cascaded Insert on Assocation - Not Just Composition?

[Ross Attrill]

Hi Laurent,

DBIDM very neatly provides cascaded insert capability for Composition() relationships.  Unfortunately, however, cascaded insert is not available for Association() relationships.

Is it intentional that cascaded insert not be available for Associations?   Since the schema generator creates Assocations by default, I don't get cascaded inserts unless I hand change my auto generated schema.

Thank you for your thoughts on this.

Regards,

Ross Attrill.

[laurent dami]

Le 02.04.2013 06:45, Ross Attrill a �crit :

> Hi Laurent,
>
> DBIDM very neatly provides cascaded insert capability for
> Composition() relationships. Unfortunately, however, cascaded insert
> is not available for Association() relationships.
>
> Is it intentional that cascaded insert not be available for Associations?

Hi Ross,

Yes it was intentional, not for technical reasons, but for conceptual
reasons. Cascaded inserts and deletes are implemented only for
compositions, in order to emphasize that the lifetime of components is
strictly included in the lifetime of the composite. The restriction was
also meant to prevent unintentional inserts (because a record hash could
easily be expanded with some keys that are named after association
names). So to use cascaded inserts or deletes, the design was to require
an explicit declaration of a composition. It would be quite easy to
change the implementation, but I'm rather reluctant to do so. If you
really need that, you could subclass Source/Table.pm and reimplement
_weed_out_subtreees; then give this class name as argument to

DBIx::DataModel->define_schema(
class => 'MySchema',
table_parent => 'My:Subclass::Of::Source::Table',
...
);

> Since the schema generator creates Assocations by default, I don't
> get cascaded inserts unless I hand change my auto generated schema.

Just out of curiosity : why do you autogenerate the schema at each time,
instead of dumping it into a file that you could customize to your
needs ? Do you change your database structure very frequently ?

Cheers, Laurent D.

[Ross Attrill]

Hi Laurent,

I understand that reasoning with the composition being a stronger relationship than the association.

The reason that I do a full schema regeneration is that I find it efficient to do so when I add a new table - which I do about once a week.   Maybe I should think about hand editing the schema now.

Thank you for your suggestion for subclassing Source/Table.pm.  I might do that.

What do you think about enhancing Schema/Generator.pm such that it was able to infer relationships that might be candidates for compositions instead of associations?   My thinking of this was that if I declare a cascaded delete or update on the database foreign key then I would create the relationship as a composition rather than association.   There seems to be enough information coming from SQL::Translator in terms of FK detail to enable this.

I will think about these options over the weekend and then start doing one of them.

Thank you again,

Ross.

On Fri, Apr 5, 2013 at 4:13 AM, laurent dami <lauren...@free.fr> wrote:

--

--- You received this message because you are subscribed to the Google Groups "dbix-datamodel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dbix-datamodel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[laurent dami]

Le 04.04.2013 23:59, Ross Attrill a écrit :

[...]

What do you think about enhancing Schema/Generator.pm such that it was able to infer relationships that might be candidates for compositions instead of associations?   My thinking of this was that if I declare a cascaded delete or update on the database foreign key then I would create the relationship as a composition rather than association.   There seems to be enough information coming from SQL::Translator in terms of FK detail to enable this.

I like that idea. The $dbh->foreign_key_info() method in DBI gives some information about cascades; indeed this could be used to infer if the relationship is likely to be a composition. I'll give it a try; however I remember that DBD drivers do not always fully implement the foreign_key_info method, so it is not guaranteed to work in all circumnstances. Which DBMS do you use ?

[Ross Attrill]

Hi Laurent, 

I am using MS SQL Server with DBD::ODBC.   For this RDBMS and DBD driver, $dbh->foreign_key_info() definitely does seem to pull in the required information:

          'DELETE_RULE' => '1' 

indicates 'No Action' while 0 indicates 'Cascade'.

Please let me know if I can help at all.

Regards,

Ross.

--
 
---
You received this message because you are subscribed to the Google Groups "dbix-datamodel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dbix-datamode...@googlegroups.com.

[laurent dami]

Done; see last commit at https://github.com/damil/DBIx-DataModel

[Ross Attrill]

Hi Laurent - thank you very much for providing this fix.

I have done some initial testing and it works perfectly (of course). 

I did have to go through my database schema and review my usage of cascaded deletes as I got a few of these messages:

<Entity> can't be a component of <AnotherEntity> (already component of <YetAnotherEntity>) at C:\src\MyProject\lib/MyApp/Schema.pm line 5.

However, that was easily enough sorted out.

Once again I am very much appreciative of your support with this.

Regards,

Ross.

--

 
---
You received this message because you are subscribed to the Google Groups "dbix-datamodel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dbix-datamode...@googlegroups.com.