[Dbix-class] Recursive update_or_create - RFC

Zbigniew Lukasiak zzbbyy at gmail.com
Tue Jul 1 09:18:19 BST 2008


On Tue, Jul 1, 2008 at 9:04 AM, Jess Robinson
<castaway at desert-island.me.uk> 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/



More information about the DBIx-Class mailing list