of these operations will succeed, regardless of the complexity
of $resultset. distinct, group_by, join, prefetch are all
supported with expected results
+ - Return value of $rs->delete is now the storage return value
+ and not 1 as it used to be
- don't pass SQL functions into GROUP BY
- Remove MultiDistinctEmulation.pm, effectively deprecating
{ select => { distinct => [ qw/col1 col2/ ] } }
correctly (RT#28451)
- "timestamp with time zone" columns (for Pg) now get inflated with a
time zone information preserved
+ - MSSQL Top limit-emulation improvements (GROUP BY and subquery support)
0.08102 2009-04-30 08:29:00 (UTC)
- Fixed two subtle bugs when using columns or select/as
=item Arguments: none
-=item Return Value: 1
+=item Return Value: $storage_rv
=back
will not run DBIC cascade triggers. See L</delete_all> if you need triggers
to run. See also L<DBIx::Class::Row/delete>.
-delete may not generate correct SQL for a query with joins or a resultset
-chained from a related resultset. In this case it will generate a warning:-
-
-In these cases you may find that delete_all is more appropriate, or you
-need to respecify your query in a way that can be expressed without a join.
+Return value will be the amount of rows deleted; exact type of return value
+is storage-dependent.
=cut
my $guard = $self->txn_scope_guard;
my $subrs_cur = $rs->cursor;
+ my $row_cnt = '0E0';
while (my @pks = $subrs_cur->next) {
my $cond;
$op eq 'update' ? $values : (),
$cond,
);
+
+ $row_cnt++;
}
$guard->commit;
- return 1;
+ return $row_cnt;
}
sub _select {