Bug #65561 for DBIx-Class-ResultSet-RecursiveUpdate: nullify related has_many objects fails due to wrong condition

Tue Feb 08 09:17:34 2011 LUKAST [...] cpan.org - Ticket created

Subject:

nullify related has_many objects fails due to wrong condition

As stated in the modules documentation, recursive_update should set the corresponding foreign keys (belonging to the related row) to NULL when updating has_many relations. Unfortunately, this will never happen, because the condition is not checked correctly. If recursive_update can nullify the corresponding columns in the related table, it sets $if_not_submitted = 'nullify'; but later checks: if($if_not_submitted eq 'set_to_null'){...} Because of this little mistake, related objects are NEVER removed from has_many-relations when using recursive_update.

Subject:

recursiveupdate_hasmany_nullify.patch

405c405 < elsif ( $if_not_submitted eq 'set_to_null' ) { --- > elsif ( $if_not_submitted eq 'nullify' ) {

Tue Feb 08 12:42:30 2011 abraxxa [...] cpan.org - Correspondence added

For me it works, please provide a failing test case.

Tue Feb 08 12:42:31 2011 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 09 08:50:25 2011 LUKAST [...] cpan.org - Correspondence added

Here is the test. I also added another patch, which changes "nullify" to "set_to_null" instead of changing "set_to_null" to "nullify". I noticed that the first patch made some of the old test fail, because they specified 'if_not_submitted => set_to_null' manualy when calling recursive_update. I guess thats the reason why you could not reproduce my failure. The failure only happens when the related ids can be set to null, and "if_not_submitted" is NOT set manually. On Tue Feb 08 12:42:30 2011, ABRAXXA wrote: Show quoted text

> For me it works, please provide a failing test case.

Subject:

nullify.patch

--- lib/DBIx/Class/ResultSet/RecursiveUpdate.pm 2011-02-09 14:42:55.000000000 +0100 +++ lib/DBIx/Class/ResultSet/RecursiveUpdate.pm.patched 2011-02-09 14:42:37.000000000 +0100 @@ -332,7 +332,7 @@ ->{is_nullable}; } - $if_not_submitted = $all_fks_nullable ? 'nullify' : 'delete' + $if_not_submitted = $all_fks_nullable ? 'set_to_null' : 'delete' unless defined $if_not_submitted; #warn "\tNULLABLE: $all_fks_nullable ACTION: $if_not_submitted\n";

Subject:

nullify_test.tar

Download nullify_test.tar
application/x-tar 10k

Message body not shown because it is not plain text.

Wed Feb 09 09:02:46 2011 abraxxa [...] cpan.org - Correspondence added

I wonder where you have the attribute from, because it isn't included in the docs, intentionally! The attribute is left from pre 0.20 to not break old code but shouldn't be used in new code and therefore isn't documented. When DBIC will get the RU feature it won't have that attribute either. If you pass an empty arrayref or undef to a has_many accessor the related rows will be deleted. That's also the first line of the docs for has_many relationship treatment. Are you on irc? Would be easier to discuss your problem with it there.

Wed Feb 09 09:18:21 2011 LUKAST [...] cpan.org - Correspondence added

I will be on irc (#dbix-class) in 15 Minutes. To clearify things: I am not using the 'if_not_submitted' parameter at all. It is set by recursive_update itself. Deleting related rows works fine, The problem only occurs if the related collumn are nullable, in which case the rows should not be deleted (as stated in the doc).

Wed Feb 09 11:30:25 2011 abraxxa [...] cpan.org - Taken

Wed Feb 09 11:36:08 2011 abraxxa [...] cpan.org - Correspondence added 60 min

fixed in https://github.com/zby/DBIx--Class--ResultSet--RecursiveUpdate/commit/986ee14c997fe16c849e26580c772db0f407875d

Wed Feb 09 11:36:09 2011 abraxxa [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Feb 11 16:06:50 2011 abraxxa [...] cpan.org - Fixed in 0.22 added