[Dbix-class] find redux

[Zbigniew Lukasiak]

On Jan 31, 2008 10:39 AM, Matt S Trout <dbix-class at trout.me.uk> wrote:
> 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)

Yes.  The problem I see is that it might be not easy (or perhaps even
impossible) to find all columns used effectively in "the search
condition already on the rs".  I mean: if it is in a clause like {
'some_col' => { '>', 100 } } then this is not enough - you need to
find conditions that really uniquely identify the value of the column.

That's why I proposed to not check if it is case 1 or case 2 - but
just assume that the user knows what he is doing - and treat
everything as case 1. Or at least add a flag for that.

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

That depends on the solution for the problem above - let's fix it
first and then discuss the rest.

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