[Dbix-class] Re: DBIx::Class::ResultSet::RecursiveUpdate - announcement and RFC

[Zbigniew Lukasiak]

On Thu, Oct 2, 2008 at 2:40 AM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> On Wed, Oct 01, 2008 at 09:38:07AM +0200, Zbigniew Lukasiak wrote:
>> On Wed, Oct 1, 2008 at 3:17 AM, Matt S Trout <dbix-class at trout.me.uk> wrote:
>> > On Tue, Sep 30, 2008 at 02:39:00PM +0200, Zbigniew Lukasiak wrote:
>> >> On Tue, Sep 30, 2008 at 2:20 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
>> >> > Well, yes. If you have an auto-increment PK and you don't have a value for
>> >> > it, then
>> >> >
>> >> > (1) there's no form field in the first place, so that's not an issue
>> >> >
>> >> > (2) you know you can't possibly find anything, so you wouldn't call
>> >> > update_or_create, you'd just call create
>> >> >
>> >> > I presume this is what Oliver's doing, which is why his code works.
>> >> >
>> >> > Nothing tricky at all.
>> >>
>> >> This method assumes that you don't get the PK in the ResultSet in the
>> >> internal conditions.  I is ok if you have the full controll over the
>> >> ResultSet - but if you do admit this possibility (for example when you
>> >> traverse a belongs_to relation, or if you use RestrictedWithObject) -
>> >> then you would have to inspect it o check what part of the PK is there
>> >> to decide if you should  go directly to ->create.  Since currently
>> >> there is no easy and sound way of doing this inspection (and for some,
>> >> rather convoluted - I admit, cases it is impossible - that is it is
>> >> undecidable - i.e. cannot be solved by an algorithm) - this makes this
>> >> method unsuitable for my purposes.
>> >
>> > I don't see that this would ever happen with an auto-inc PK though.
>> >
>> > And if it's a unique key, the behaviour is rather different.
>> >
>> > Basically, I've not yet seen a real world example where this situation
>> > actually comes up, and I can't think of a contrived one that doesn't come
>> > into the category of "your design is broken".
>> >
>> > So it's so far a problem in theory but not in practice - can you provide
>> > a real example of this situation?
>>
>> 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.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/