[Dbix-class] find redux

[Zbigniew Lukasiak]

On Jan 28, 2008 5:19 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
>
> 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'
>

Another reason why this example is not really that pathological.  Let
say you want to write a subroutine that takes as inputs a row, a
relation and a query.  Inside of that sub you need to do:

$row->find_related( $relation, $query, { key => primary} )

And you want it to work independently of the type of the relation.

In the terms of our example this would be:

$cd->find_related( 'artist', { name => 'some other name' }, { key => primary } )

and this would be translated to:

$schema->resultset("Artist")->search( { artistid =>
$cd->artist->artistid } )->find( { name => 'some other name' }, { key
=> 'primary' } );

--
Zbigniew