[Dbix-class] find redux

[Zbigniew Lukasiak]

On Jan 28, 2008 4:43 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> On Fri, Jan 25, 2008 at 05:10:07PM +0100, Zbigniew Lukasiak wrote:
> > On Jan 25, 2008 2:30 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> > > On Fri, Jan 25, 2008 at 12:24:27PM +0100, Zbigniew Lukasiak wrote:
> > > > Let me sidestep that a bit
> > >
> > > No, I won't let you.
> > >
> > > I spent an hour discussing with people how to structure this discussion so
> > > we can actually work out how to proceed in a framework that's clear, precise
> > > and reasonably easy to convert across to code.
> > >
> > > Please do me the courtesy of respecting the effort that went into this
> > > and working within the structure provided.
> >
> > OK, if that will help you I am happy to provide that help.
> >
> > I am not sure what you meant in the end note - I'll assume here that
> > it means that when you say 'all columns' you mean the columns in the
> > query and in the internal resultset condition.  Correct me if I am
> > wrong.  This question of including the 'implicite rs columns' is the
> > most important thing in this whole analysis - because it is the least
> > understood one.  My opinion is that those columns should be included.
> >
> > And assuming that I differ with you in the analysis of
> >
> > Case 1 - called with 'key' attr and all columns for that key
> >
> > If all the key columns are in the query then the behaviour is correct,
> > but if one of the columns for the key is in the condition instead of
> > the query then a search by all columns will be issued.
>
> Hrm. That's it seeing it as case 2 when it should be case 1.
>
> > The Case 1 is the most important one to fix.
>
> Fortunately, case 1 already works.
>
> Now, please try again, reading my e-mail more carefully.
>
> And this time reply to the original message as requested.

I think you are referring to your note about *_or_* methods, but I'll
show that this is not relevant i.e. you can easily reproduce the
behaviour without using the *_or_* methods.
So here is the example translated to pure find:

my $cd = $schema->resultset("CD")->first;
my $artist_rs = $schema->resultset("Artist")->search( { artistid =>
$cd->artist->artistid } );
$schema->storage->debug(1);
$artist_rs->find( { name => 'some other name' }, { key => 'primary' } );
__OUTPUT__

t/61findnot......SELECT me.artistid, me.name FROM artist me WHERE ( (
( me.name = ? ) AND ( artistid = ? ) ) ): 'some other name', '1'

As you can see it still searches by all columns, even if it has the pk
in the resultset condition.  This example of course looks a bit
pathological - but what if you had a composed pk and did something
along the lines:

my $rs = $schema->resultset("SomeTable")->serach( { first_pk_part =>
'some value' } );
$rs->find( { second_pk_part => 'some val', name => 'some other name' } );

This does not look so pathological any more - but the same thing will
happen - i.e. search by all columns.  And if you reject composed
primary key as too exotic case then what about other composed unique
conditions?

The point is that the assumptions about find that were made by the
authors of the *_or_* methods are not something exceptional - and I
would expect that in the future other people will do similar
assumptions.

-- 
Zbigniew Lukasiak
http://perlalchemy.blogspot.com/