All expected evals converted to try, except where no test is done,

[dbsrgits/DBIx-Class.git] / lib / DBIx / Class / Relationship / Base.pm

diff --git a/lib/DBIx/Class/Relationship/Base.pm b/lib/DBIx/Class/Relationship/Base.pm
index 2f8083a..e533117 100644 (file)
--- 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 { $cond = $source->_resolve_condition( $rel_info->{cond}, $rel, $self ) }
+    catch {
       if ($self->in_storage) {
-        $self->throw_exception ($err);
+        $self->throw_exception ($_);
       }
       else {
         $cond = $DBIx::Class::ResultSource::UNRESOLVABLE_CONDITION;
       }
-    }
+    };
 
     if ($cond eq $DBIx::Class::ResultSource::UNRESOLVABLE_CONDITION) {
       my $reverse = $source->reverse_relationship_info($rel);