[R-sig-DB] Add a "dbSendUpdate" function to DBI?

[MacQueen, Don]

Speaking as an end-user, not a package developer, I think that for
consistency with current behavior of the functions I frequently use (see
one of Denis Mukhin¹s emails early in this thread), I¹d prefer that this
new function throw an error when the DB throws an error. Admittedly, I
don¹t have a deep understanding of the issues involved.

If within a script I send an SQL statement to the DB in which, for
example, I refer to a nonexistent table, the DB reports that as an error.
It makes sense to me that the R function would do the same, which
immediately stops my script. It¹s telling me I¹ve got an error that *must*
be fixed. I would prefer being stopped, rather than having to test
(perhaps that¹s being lazy on my part, but the Œerror¹ behavior is more
protective).

-Don

-- 
Don MacQueen

Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062





On 9/4/14, 12:15 PM, "Hadley Wickham" <h.wickham using gmail.com> wrote:

>> It is the "If the API" part that I worry about. For example
>>
>>> success(warning("warn"))
>> Warning message:
>> In doTryCatch(return(expr), name, parentenv, handler) : warn
>>> is.logical(success(warning("warn")))
>> [1] FALSE
>> Warning message:
>> In doTryCatch(return(expr), name, parentenv, handler) : warn
>>>
>>
>> So then every package writer trying to build on DBI has to write a
>>wrapper
>> that anticipates the exceptions that may be thrown. This becomes even
>>more
>> difficult when different db drivers, different OSes, and different
>>servers
>> are involved.
>
>I'm not sure I follow, because we hadn't talked about warnings. I
>would not expect that DBI backends to through warnings instead of
>errors.
>
>> Given the philosophical constraint I think I would generally prefer the
>> function that is guaranteed to return a logical. The other wrapper is
>>easy
>> to write too.
>
>But it's fundamentally more dangerous. If all modification functions
>return TRUE or FALSE and you don't explicit check the return value, it
>is extremely easy to create invalid code. The same is not true for
>errors.
>
>Hadley
>
>
>-- 
>http://had.co.nz/
>
>_______________________________________________
>R-sig-DB mailing list -- R Special Interest Group
>R-sig-DB using r-project.org
>https://stat.ethz.ch/mailman/listinfo/r-sig-db