2008/10/2 Zbigniew Lukasiak <zzbbyy@gmail.com>:
> On Thu, Oct 2, 2008 at 2:40 AM, Matt S Trout <dbix-class@trout.me.uk> 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
Highlight