[Dbix-class] find redux

[Zbigniew Lukasiak]

On Feb 14, 2008 10:47 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> On Thu, Feb 14, 2008 at 3:04 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> >
> > On Wed, Feb 13, 2008 at 08:31:42PM +0100, Zbigniew Lukasiak wrote:
> >  > On Feb 13, 2008 5:51 PM, Guillermo Roditi <groditi at gmail.com> wrote:
> >  > > > I attach a patch (against
> >  > > > http://dev.catalyst.perl.org/repos/bast/DBIx-Class/0.08/trunk) that
> >  > > > does more or less that - when you specify the unique key it ignores
> >  > > > all columns from the query that don't belong to it (
> >  > >
> >  > > I find this to be desired behavior Zbigniew Lukasiak++
> >  >
> >  > Thanks.  Frankly I don't think that warning is necessary - I like to
> >  > use find directly from the query parameters without removing all the
> >  > unneeded columns.  Without it that patch is even more trivial
> >  > (attached here).
> >
> >  Looks good. Fancy doing the warn-if-more-than-one-result bit while you're
> >  in there as well?
>
> Attached.  I think it could even croak in that case.

Now, waiting for this to be committed, here is the problem with the
*_or_* methods: Pg will not accept an INSERT with the primary key set
to NULL and on the other hand the "find" method will not accept a
query without the primary key.  So if you have a primary key that is
generated by the database from a sequence (e.g. SERIAL) then you need
calls for "find" and for "insert" use different parameters - for
"find" you would use { pk => undef, @other_params } and for "insert" {
@other_params }.  That is the *_or_* methods cannot just pass the same
query to both "find" and "update", "create" and "new".

Possible solutions:

1) Delete the pk from the parameters or set it to 'DEFAULT' if it is
set to undef in the call to "insert" in Storate::Pg.  This would make
insert work a bit more consistently across databases.  Unfortunately
Matt is against that solution on the basis that "insert" should always
interpret undef as NULL.

2) Check if we have primary key set to undef in the *_or_* methods and
delete it from the parameters passed to the "create" and "new"
methods.

3) Check if we have primary key set to undef in the *_or_* methods and
not call "find" in those cases at all - because we know it would fail
- and just call "create" or "new".

I like the option 1) - because it makes DBIC a bit more database
independent and also because the 2) and 3) options introduce
additional inconsistency between the calls to "find_or_create"
("find_or_new") and "create" ("new") (for the first two you include
the null pk in the call for the other two you should delete it).  But
more important than the differences is to agree on one of these
options.

Cheers,
Zbigniew