Re: Recursive update_or_create - RFC

Previous Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Recursive update_or_create - RFC

Jess Robinson

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/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: Recursive update_or_create - RFC

Zbigniew Lukasiak
On Tue, Jul 1, 2008 at 9:04 AM, Jess Robinson
<[hidden email]> 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/dbix-class@...