[Dbix-class] find redux

[Zbigniew Lukasiak]

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


Let me sidestep that a bit, and also sorry for mostly repeating what I
said in the other thread - but this is in much more detail.

Lets define

USER_PROVIDED_CORRECT_QUERY - means that the query combined with the
resultset condition contains at least one full unique constraint (or
contain the unique constraint specified by the user)

The current behaviour is:

IF guess( USER_PROVIDED_CORRECT_QUERY ){
    IF there is a record identified by the chosen unique condition {
        return that found record
    }
    else{
        return undef
    }
}
else{
    IF there is a record identical to all columns of the query{
        return that record
    }
    else {
        return undef
    }
}


What I would like to have is that

IF USER_PROVIDED_CORRECT_QUERY {
  IF there is a record identified by the chosen unique condition {
        return that found record
    }
    else{
        return undef
    }
}
else {
    UNDEFINED - I don't care what happens here
}

The difference is that the user does not need to think about the
guessing algorithm that checks the query - and he can be sure that
when he provides a correct query then he will receive the correct
answer (which is the found record or undef if there is no such
record).

This behaviour can be switched on with a special flag.
-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/