X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FRelationship%2FBase.pm;h=53dc14cd143a8e1f2f8c204ab2530f0f5b25b724;hb=f43ea814d6c4c181aeaac244c5db17058aac3d5e;hp=2f8083ab4f216cf4b817345007ec3156c544699b;hpb=5f7ac523d6179423620e5d20a83d3245a2f29385;p=dbsrgits%2FDBIx-Class-Historic.git

diff --git a/lib/DBIx/Class/Relationship/Base.pm b/lib/DBIx/Class/Relationship/Base.pm
index 2f8083a..53dc14c 100644
--- a/lib/DBIx/Class/Relationship/Base.pm
+++ b/lib/DBIx/Class/Relationship/Base.pm
@@ -5,6 +5,7 @@ use warnings;
 
 use Scalar::Util ();
 use base qw/DBIx::Class/;
+use Try::Tiny;
 
 =head1 NAME
 
@@ -127,14 +128,17 @@ of when to create constraints.
 If C<cascade_copy> is true on a C<has_many> relationship for an
 object, then when you copy the object all the related objects will
 be copied too. To turn this behaviour off, pass C<< cascade_copy => 0 >> 
-in the C<$attr> hashref. The behaviour defaults to C<< cascade_copy => 1 >>.
+in the C<$attr> hashref. 
+
+The behaviour defaults to C<< cascade_copy => 1 >> for C<has_many>
+relationships.
 
 =item cascade_delete
 
-By default, DBIx::Class cascades deletes across 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.
+By default, DBIx::Class cascades deletes across C<has_many>,
+C<has_one> 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,
 so if your database has a constraint on the relationship, it will
@@ -143,15 +147,15 @@ before DBIx::Class gets to perform the cascaded operation.
 
 =item cascade_update
 
-By default, DBIx::Class cascades updates across C<has_many> and
+By default, DBIx::Class cascades updates across C<has_one> and
 C<might_have> relationships. You can disable this behaviour on a
-per-relationship basis by supplying C<< cascade_update => 0 >> in the
-relationship attributes.
+per-relationship basis by supplying C<< cascade_update => 0 >> in
+the relationship attributes.
 
-The cascaded operations are performed after the requested update,
-so if your database has a constraint on the relationship, it will
-have updated/updated the related records or raised an exception
-before DBIx::Class gets to perform the cascaded operation.
+This is not a RDMS style cascade update - it purely means that when
+an object has update called on it, all the related objects also
+have update called. It will not change foreign keys automatically -
+you must arrange to do this yourself.
 
 =item on_delete / on_update
 
@@ -234,15 +238,16 @@ sub related_resultset {
 
     # condition resolution may fail if an incomplete master-object prefetch
     # is encountered - that is ok during prefetch construction (not yet in_storage)
-    my $cond = eval { $source->_resolve_condition( $rel_info->{cond}, $rel, $self ) };
-    if (my $err = $@) {
+    my $cond = try {
+      $source->_resolve_condition( $rel_info->{cond}, $rel, $self )
+    }
+    catch {
       if ($self->in_storage) {
-        $self->throw_exception ($err);
-      }
-      else {
-        $cond = $DBIx::Class::ResultSource::UNRESOLVABLE_CONDITION;
+        $self->throw_exception ($_);
       }
-    }
+
+      $DBIx::Class::ResultSource::UNRESOLVABLE_CONDITION;  # RV
+    };
 
     if ($cond eq $DBIx::Class::ResultSource::UNRESOLVABLE_CONDITION) {
       my $reverse = $source->reverse_relationship_info($rel);