[Bast-commits] r4792 - in DBIx-Class/0.08/trunk/lib/DBIx/Class: . Manual

[castaway at dev.catalyst.perl.org]

Author: castaway
Date: 2008-08-31 13:01:25 +0100 (Sun, 31 Aug 2008)
New Revision: 4792

Modified:
   DBIx-Class/0.08/trunk/lib/DBIx/Class/Manual/FAQ.pod
   DBIx-Class/0.08/trunk/lib/DBIx/Class/Relationship.pm
Log:
Added doc patches from g about cascade_delete


Modified: DBIx-Class/0.08/trunk/lib/DBIx/Class/Manual/FAQ.pod
===================================================================
--- DBIx-Class/0.08/trunk/lib/DBIx/Class/Manual/FAQ.pod	2008-08-31 01:55:17 UTC (rev 4791)
+++ DBIx-Class/0.08/trunk/lib/DBIx/Class/Manual/FAQ.pod	2008-08-31 12:01:25 UTC (rev 4792)
@@ -77,7 +77,7 @@
 
 =item .. tell DBIx::Class about relationships between my tables?
 
-There are a vareity of relationship types that come pre-defined for
+There are a variety of relationship types that come pre-defined for
 you to use.  These are all listed in L<DBIx::Class::Relationship>. If
 you need a non-standard type, or more information, look in
 L<DBIx::Class::Relationship::Base>.
@@ -113,13 +113,20 @@
 
 Read the documentation on L<DBIx::Class::Relationship/many_to_many>.
 
-=item .. stop DBIx::Class from attempting to cascade deletes on my has_many relationships?
+=item .. stop DBIx::Class from attempting to cascade deletes on my has_many and might_have relationships?
 
 By default, DBIx::Class cascades deletes and updates across
-C<has_many> relationships. If your database already does this (and
-that is probably better), turn it off by supplying C<< cascade_delete => 0 >>
-in the relationship attributes. See L<DBIx::Class::Relationship::Base>.
+C<has_many> and C<might_have> relationships. You can disable this
+behaviour on a per-relationship basis by supplying
+C<< cascade_delete => 0 >> in the relationship attributes.
 
+The cascaded operations are performed after the requested delete or
+update, so if your database has a constraint on the relationship, it
+will have deleted/updated the related records or raised an exception
+before DBIx::Class gets to perform the cascaded operation.
+
+See L<DBIx::Class::Relationship>.
+
 =item .. use a relationship?
 
 Use its name. An accessor is created using the name. See examples in
@@ -294,11 +301,11 @@
 
 Then call L<DBIx::Class::ResultSet/slice> and ask it only to return 1 row:
 
-  ->slice(0,1)
+  ->slice(0)
 
 These two calls can be combined into a single statement:
 
-  ->search->(undef, { order_by => "id DESC" })->slice(0,1)
+  ->search->(undef, { order_by => "id DESC" })->slice(0)
 
 Why slice instead of L<DBIx::Class::ResultSet/first> or L<DBIx::Class::ResultSet/single>?
 If supported by the database, slice will use LIMIT/OFFSET to hint to the database that we

Modified: DBIx-Class/0.08/trunk/lib/DBIx/Class/Relationship.pm
===================================================================
--- DBIx-Class/0.08/trunk/lib/DBIx/Class/Relationship.pm	2008-08-31 01:55:17 UTC (rev 4791)
+++ DBIx-Class/0.08/trunk/lib/DBIx/Class/Relationship.pm	2008-08-31 12:01:25 UTC (rev 4792)
@@ -330,10 +330,13 @@
 
 If you delete an object in a class with a C<has_many> relationship, all
 the related objects will be deleted as well.  To turn this behaviour off,
-pass C<< cascade_delete => 0 >> in the C<attr> hashref. However, any
-database-level cascade or restrict will take precedence over a
-DBIx-Class-based cascading delete.
+pass C<< cascade_delete => 0 >> in the C<$attr> hashref.
 
+The cascaded operations are performed after the requested delete or
+update, so if your database has a constraint on the relationship, it
+will have deleted/updated the related records or raised an exception
+before DBIx::Class gets to perform the cascaded operation.
+
 If you copy an object in a class with a C<has_many> relationship, all
 the related objects will be copied as well. To turn this behaviour off,
 pass C<< cascade_copy => 0 >> in the C<$attr> hashref. The behaviour
@@ -414,9 +417,13 @@
 If you update or delete an object in a class with a C<might_have>
 relationship, the related object will be updated or deleted as well. To
 turn off this behavior, add C<< cascade_delete => 0 >> to the C<$attr>
-hashref. Any database-level update or delete constraints will override
-this behavior.
+hashref.
 
+The cascaded operations are performed after the requested delete or
+update, so if your database has a constraint on the relationship, it
+will have deleted/updated the related records or raised an exception
+before DBIx::Class gets to perform the cascaded operation.
+
 See L<DBIx::Class::Relationship::Base> for documentation on relationship
 methods and valid relationship attributes.