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

[Zbigniew Lukasiak]

On Mon, Sep 29, 2008 at 2:43 PM, Aristotle Pagaltzis <pagaltzis at gmx.de> wrote:
> * Zbigniew Lukasiak <zzbbyy at gmail.com> [2008-09-29 09:15]:
>> RecursiveUpdate does not require that you have additional
>> unique constraints on tables with auto_increment primary keys
>> like the original update_or_create does.
>
> If none of the columns you pass is unique, how does it decide
> which set of columns to use in the WHERE condition and which are
> the ones to use as new values?

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 - but then when
traversing belongs_to (and might_have) relations I would not be able
to let the user omit the PK and rely on the fact that it is
implicitely specified in the resultset

I think my solution leads to simpler usage.

I understand that from low-level code you would expect that if you
specify { column => undef } - for an update relation - then it would
result in an insert with NULL in the place of the column with no
exceptions.  I am breaking that expectation in a way - but I view my
code as one level higher abstraction then DBIC itself and I hope that
by documenting it I am guarding enough the user of my library from
surprises.


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