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

[Zbigniew Lukasiak]

On Mon, Sep 29, 2008 at 11:40 PM, Oliver Gorwits
<oliver.gorwits at oucs.ox.ac.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Zbigniew Lukasiak wrote:
>> It works only with primary keys.  And if you supply 'undef' in
>> the place of the auto_increment  PK then it knows that this will
>> be a new row.  This is an additional convention that I add over
>> the DBIC semantics - I don't insist that it is elegant but
>> without it I would have two options:
>> - an additional parameter to
>> specify if the operation on a given row is an update or a create
>> - require that the user adds additional constraints
>
> Here's pseudocode for what I do in LFB:
>
> # eval{ search for row with PK(s) matching user data PK(s) }
> # if result is blessed
> #     then user is asking for an update, so do set_columns
> # else,
> #     user is asking for new row, so do new_result
> # do update_or_insert.
>
> No PK hint is required, here.
>
> In the case where there aren't auto-generated PK values, and the
> user supplies them, then the eval{} still fails, causing a new_result.

So you say that you call ->find( { pk => undef, ... } ) ( or ->search(
{ pk => undef } )->next ) in that case?  This works of course - it
will not find any row - just as you need and this is exactly what I do
in recursive_update - as described above.

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.


>
> What scenario is missing from the above, I'd be interested to know ?

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