Re: "Upcalls" (sort of) from the database

Bernhard Weisshuhn wrote:
> Don Y wrote:

[snip]

>> For example, the title may match an existing entry -- but
>> the author may be different (e.g., misspelled, or some
>> "other" author listed on a book having multiple authors, etc.).
>> Ideally, I would like the database to suspend the INSERT,
>> ask for confirmation (and "why") and then, either commit
>> the INSERT or abort it (based on the user's response).
>>
>> Nearest I can imagine, there's only one ways I can do this:
>> issue a query that looks for these types of problems and
>> based on the result, let the *application* prompt the
>> user for confirmation.  Then, *if* confirmed, do the real
>> INSERT.
>
> You could *insert* the data and then *rollback* the transaction. Then
> you would *know* the data is *valid*.
> Only if the user *confirms* the action, then you do it *again* and
> actually *commit* the transaction.

Ah, OK.  More elegant.  But, it still moves responsibility for this
to the application layer, not the database, itself.  I can't see
any way of avoiding this :-(

OTOH, an API with like insert_data(...., bool confirm) would
remind the application developers that the intended interface
is:

switch (insert_data(..., FALSE)) {
    case INVALID:
    /* something wonky in the data, abort */
        break;
    case QUESTIONABLE:
    /* possible typographical error, require confirmation */
        if (confirmed)
            insert_data(..,TRUE);
        break;
    case LOOKS_GOOD:
        insert_data(..., TRUE);
}

> P.S. these* *stars* are *unnerving* ;-)

<frown>  Sorry, i've been writing specifications for the past
few days and use the "emphasis" SGML tag quite a bit  :-/
(the idea of posting in HTML is just anathema...)

--don