=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/ _______________________________________________ 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/[EMAIL PROTECTED]