[Dbix-class] find redux

[Matt S Trout]

On Wed, Jan 30, 2008 at 07:57:02PM +0100, Zbigniew Lukasiak wrote:
> Hi Matt,
> 
> You are a mystery to me - but I'll try to comply and interleave my
> comments with your original post as you wish.
> 
> On Jan 24, 2008 1:14 PM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> > =head1 calling cases
> >
> > Case 1 - called with 'key' attr and all columns for that key[0]
> > Case 2 - called with 'key' attr and not all columns for that key
> >
> > Case 3 - called without 'key' attr and with a unique key's worth of cols[0]
> > Case 4 - called without key and no unique set of columns
> >
> > =head1 08000
> >
> > Current behaviour (I think, please correct me if I'm wrong):
> >
> > 1: does the expected query, ignoring other columns
> 
> This is not true.  Here is example:
> 
> 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' }
> );  # this is the query
> 
> __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 it did not ignore the 'name' column.

So what you're basically saying is, if one or more of the columns for the
key comes from the search condition already on the rs rather than find,
it treats it as case 2 when it should treat it as case 1? (and presumably
similarly where the key attr isn't supplied the case 4 code path is followed
when case 3 should be)

Is that the only behaviour that (as you see it) needs fixing for *_or_*
methods to work correctly?

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/