[Dbix-class] find redux

[Matt S Trout]

=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

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/