2008/10/2 Zbigniew Lukasiak <[EMAIL PROTECTED]>: > On Thu, Oct 2, 2008 at 2:40 AM, Matt S Trout <[EMAIL PROTECTED]> wrote: >> On Wed, Oct 01, 2008 at 09:38:07AM +0200, Zbigniew Lukasiak wrote: >>> The example that I am mostly concerned with is: >>> >>> $cd_rs->recursive_update( { title => 'New Title', artist => { name => >>> 'New Name' } } ) >>> >>> Now when traversing the relation from cd to the artist I get the >>> artist resultset with the PK constrained in the ->{cond}. There is >>> just one artist that the cd 'belongs_to' - and that artist should be >>> updated. But there is no PK passed in the parameters - so if we just >>> look at the parameters we would conclude that this would require a >>> ->create call. >> >> Ah, because the artist is about to be changed? >> >> In that case you should create the artist separately and then assign it >> I think, which again avoids the problem. >> > > Perhaps I did not explain it enough - I want that call to result in an > update not a create. An update to the only artist that 'belongs_to' > the cd.
( /me steps into a minefield ) I would suggest that if it's an update, you should already have the artist PK - keep ahold of it when you're initially getting the vales from the DB. Then, when you're doing the update, verify the PK hasn't changed (or maybe allow it to be configured to allow rel ID changes). I know FormFu doesn't do that, it can just follow the relationship name, so you don't need a hidden field for the related PK - but I feel it's more flexible to handle traversing the relationships ourselves, rather than using a core DBIC recursive-update. Carl _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]