[Dbix-class] find redux

[Matt S Trout]

On Thu, Jan 31, 2008 at 11:09:19AM +0100, Zbigniew Lukasiak wrote:
> 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.

I'm not sure I understand how the required code for this is any
different - either way you have to find the equality conditions in
the query for columns within that key.

The point here is case 1 is "use only the subset of the query
corresponding to the unique key" and case 2 is "use the whole query". If
we're trawling for a subset, we're trawling for a subset - you can't do
.

Unless you mean something different - what exactly are you talking about
here by "treat everything as case 1" ?
 
> >
> > 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.

Without knowing the rest of the parameters we can't choose a solution.

Answer the question please.

-- 
      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/