X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FRow.pm;h=134e841524938ff299bcbf066024eecaf52a1789;hb=7e51afbf1951bc8febf00897e5e3f0f25dfc34aa;hp=c1fb2b0e2b6d5b51bb3f665f61b1789ac102ee9b;hpb=a7be8807654bc18bcae13a3f6ee30075d91aaca9;p=dbsrgits%2FDBIx-Class-Historic.git

diff --git a/lib/DBIx/Class/Row.pm b/lib/DBIx/Class/Row.pm
index c1fb2b0..134e841 100644
--- a/lib/DBIx/Class/Row.pm
+++ b/lib/DBIx/Class/Row.pm
@@ -450,6 +450,14 @@ hashref of the relationship, see L<DBIx::Class::Relationship>. Any
 database-level cascade or restrict will take precedence over a
 DBIx-Class-based cascading delete. 
 
+If you delete an object within a txn_do() (see L<DBIx::Class::Storage/txn_do>)
+and the transaction subsequently fails, the row object will remain marked as
+not being in storage. If you know for a fact that the object is still in
+storage (i.e. by inspecting the cause of the transaction's failure), you can
+use C<< $obj->in_storage(1) >> to restore consistency between the object and
+the database. This would allow a subsequent C<< $obj->delete >> to work
+as expected.
+
 See also L<DBIx::Class::ResultSet/delete>.
 
 =cut