On Tue, Jul 1, 2008 at 9:04 AM, Jess Robinson <[EMAIL PROTECTED]> wrote: > > On Thu, 19 Jun 2008, Zbigniew Lukasiak wrote: > >> more difference from update_or_create - it will work on tables with >> auto_increment primary keys - you just need to set the key to 'undef' >> - then it will be deleted from the INSERT sent to the database (this >> will only happen for auto_increment keys - other columns will be set >> to 'NULL' just as usual). This is additional complexity of the >> semantics - but with the benefit of more universal and uniform usage. >> > > I'm late to this somewhat long thread but.. (and I think I mentioned this > before).. The whole "insert doesnt like null values in PK fields" thing is > db-specific. > > I would say that insert itself needs to figure this out, in storage, based > on what type of database is being dealt with. Systems that don't like having > a NULL inserted into a nullable field (the PK), generally accept \'DEFAULT' > instead. > > This shouldn't be up to the user, and as was mentioned, cant be chosen by > the user in case of update_or_create anyway. If it gets as far as insert > then storage needs to check for pk values, and if present but undef, set > them to the preferred thing for the current storage.. > > Am I making any sense?
This would be the ideal solution for me. -- 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]
