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

[Zbigniew Lukasiak]

On Wed, Oct 1, 2008 at 1:18 AM, Oliver Gorwits
<oliver.gorwits at oucs.ox.ac.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Zbigniew Lukasiak wrote:
>> 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.
>
> I think that "special treatment" should set off alarm bells in your
> head. It's a sign that either this is a path to insanity, or just
> incorrect design which will not scale.

I can understand that programmers don't like "special treatments" -
because it complicates things and is easy to forget.  But for my
defense I put that I feel safer knowing that my design will work for
all cases.  Catering for some hypothetical scaling or other future
possibilities more then current real setup cases does not sound
rational for me.  And remembering just one simple rule is for me
easier then remembering all the cases where it would break.

>
> To my mind the best thing to do would be drop the requirement to
> cater for "all possible cases" - after all that's not what Perl/CPAN
> is about; it's about catering for a set of cases for *some* systems,
> and somebody else can deal with the other cases.
>

That is not that easy - traversing a belongs_to relation is not
unusual thing to do.

> The PK => undef hint is just that, a hint, and hints are by
> definition disposable, hence not required, and therefore not necessary.
>

Yeah - maybe we should do that PK checking - this would also let
people use update_or_create for tables with auto_increment keys.

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