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? Jess _______________________________________________ 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]
