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

[Zbigniew Lukasiak]

OK - so here is an improved reply.

On Tue, Sep 30, 2008 at 2:39 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> On Tue, Sep 30, 2008 at 2:20 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
>> On Tue, Sep 30, 2008 at 09:28:50AM +0200, Zbigniew Lukasiak wrote:
>>> The tricky part is when you load data from the form into the new row.
>>> You need to delete the pk from it - because otherwise at
>>> update_or_insert time it would issue an insert with pk = NULL - and
>>> this will fail in Pg (for example).  The point is that you cannot feed
>>> the same data to the find and to the insert calls - but
>>> update_or_create does that - and why it does not have much choice is
>>> another very long story.
>>
>> 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.

If we don't care about all possible predicates resulting in a unique
constraint on the PK - and only count the equalities (that is 'pk >=
1' is filtered out, 'pk = 2' stays) - then it is obviously decidable.
If $rs->{cond} is a normal SQL::Abstract structure then it should not
be that difficult to write this PK checker.  I know you decided that
this can wait for the 0.9 version - but if you changed your mind I
think I can write that.

For the time being the convention with special treatment for {pk =>
undef} is the only way that I can implement something covering all the
possible cases.


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