On Wed, Oct 1, 2008 at 1:18 AM, Oliver Gorwits <[EMAIL PROTECTED]> 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/ _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]