[Dbix-class] find redux

Zbigniew Lukasiak zzbbyy at gmail.com
Wed Jan 30 18:57:02 GMT 2008


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.

>
> 2: behaves same as 4
>
> 3: does an OR of all unique keys it finds? uses the first one?
>
> 4: dumps the query into search() and hopes
>
> =head1 better behaviour: find()
>
> We tried making (4) warn but it turns out lots of stuff relies on it,
> although I think warning by default in 09000 should be sensible and we
> could put in an option to turn it on in 08100.
>
> (2) is the nasty one, and since I can't see you ever specifying a key
> without wanting it used I'd suggest this should die, maybe as soon as 08100
> (if not, warn in 08100 and die in 09000).
>
> =head1 (find|update)_or_(create|new)(_related)?
>
> Now, the *_or_* methods currently just pass their stuff through to find().
>
> I think in the case of (2) -they- should simply not call find at all - if
> you specify "by pk" but there's no pk col passed clearly it has to be
> an insert.
>
> I'm not sure what we do in the case of 3/4 - possibly provide key 'primary'
> by default? I think that's usually what no-key-attr usages -mean- to be.
>
> If not, they should certainly pass through the option that says "warn
> loudly if no unique key present".
>
> =head1 multi-create
>
> A separate issue which seems to have got conflated in this discussion is
> that multi-create currently always calls find_or_create. Trouble with
> that is if there isn't actually a unique key involved this hits the (4)
> behaviour, or "make shit up and hope".
>
> The fix for this is that we need to check to see if the supplied columns
> constitute a unique key - if they don't then call new, not
> find_or_new. To explain this -
>
> { ... event => { event_type => $type } ... }
>
> where event_type isn't unique, we should always create()
>
> { ... event_type => { type => $type } ... }
>
> where type is unique, we should find_or_create (lookup table, which is
> the most common situation and hence the one multi-create currently
> covers - remember when Jess posted several times saying "this doesn't have
> enough tests please write some"? ...)
>
> =head1 end notes
>
> [0] or some of the columns and the others are implicit on the rs, the two
> cases are equivalent
>
> --
>       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/
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.rawmode.org
>



Cheers,
Zbigniew Lukasiak
http://perlalchemy.blogspot.com/



More information about the DBIx-Class mailing list