On 09/04/2014 10:53 AM, Hadley Wickham wrote:
The problem with that approach is that you end up with a lot of code like:
if (!dbBegin(con)) stop(dbGetException())
...
if (!dbExecute(con, sql)) stop(dbGetException())
...
if (!dbCommit(con)) stop(dbGetException())
where the developer is responsible for always checking that the
operation succeeded. If you throw an error, then the code is simpler:
dbBegin(con)
...
dbExecute(con, sql)
...
dbCommit(con)
I think this depends on the code. There are frequently situations where
it is nice to have a function that is certain to return a logical value,
so not have to catch exceptions and parse for all possibilities. (BTW,
if error message text is to be returned then that can be set as an
attribute to the logical value.) My feeling is it would be nice to have
both, one function certain to return a logical, and one that will throw
an error. If one is a simple wrapper to the other then only one method
needs to be implemented and the DBI default can look after the other.
Paul
Given that we're using a language with exceptions, it seems better to
use them, rather than adopting the standard C error handling
mechanism.
Hadley
On Thu, Sep 4, 2014 at 9:45 AM, Peter Meißner
<peter.meiss...@uni-konstanz.de> wrote:
IMHO
the general approach should be:
- as long as R does deliver the the queries to the DB and the DB does give
response there should never ever be an R error - the function did what it
should do: making sure things were delivered to DB
- the return than should depend on what the DB said:
* 0/TRUE - no error, nothing else to say
* 1/FALSE - DB does complain somehow
* text/whatever appropriate - something was returned, ...
- if however connection was lost during the execution of the function so it
cannot be sure delivery went as expected an error should be issued
Best, Peter
Am 04.09.2014 16:28, schrieb Denis Mukhin:
In ROracle we standardized on the second approach, namely always return
TRUE, otherwise throw an error.
Also since UPDATE is not the only operation that does not return any
results (although it might with a RETURNING clause) would a more generic
name be more appropriate here? Besides DMLs there are also DDLs. Something
like dbExecute(), dbSubmit(), dbSend() ...
Denis
-----Original Message-----
From: Hadley Wickham [mailto:had...@rstudio.com]
Sent: Thursday, September 04, 2014 9:13 AM
To: MacQueen, Don
Cc: Simon Urbanek; R-sig-DB@r-project.org
Subject: Re: [R-sig-DB] Add a "dbSendUpdate" function to DBI?
A thought: should dbSendUpdate() return a boolean indicating success, or
always return TRUE, otherwise throwing an error?
Hadley
On Wed, Sep 3, 2014 at 3:59 PM, MacQueen, Don <macque...@llnl.gov> wrote:
Hadley,
Since you mentioned DBI 0.3 in a recent email, could I make a request
to add a dbSendUpdate() function to DBI, like the one in RJDBC?
require(RJDBC)
find('dbSendQuery')
[1] "package:RJDBC" "package:DBI"
find('dbSendUpdate')
[1] "package:RJDBC"
And from ?dbSendUpdate
'dbSendQuery' and 'dbSendUpdate' submit a SQL query to the
database. The difference between the two is only that
'dbSendUpdate' is used with DBML queries and thus doesn't return
any result set.
I would find this helpful, because I could then use scripts unmodified
with either ROracle or RJDBC.
(I suppose adding it to DBI would mean that the one in RJDBC would
have to be modified.)
I have:
Package Version
"DBI" "0.3.0"
Package Version
"RJDBC" "0.2-4"
Thanks
-Don
--
Don MacQueen
Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062
--
http://had.co.nz/
_______________________________________________
R-sig-DB mailing list -- R Special Interest Group R-sig-DB@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-db
_______________________________________________
R-sig-DB mailing list -- R Special Interest Group
R-sig-DB@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-db
--
Peter Meißner
Workgroup 'Comparative Parliamentary Politics'
Department of Politics and Administration
University of Konstanz
Box 216
78457 Konstanz
Germany
+49 7531 88 5665
http://www.polver.uni-konstanz.de/sieberer/home/
_______________________________________________
R-sig-DB mailing list -- R Special Interest Group
R-sig-DB@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-db
_______________________________________________
R-sig-DB mailing list -- R Special Interest Group
R-sig-DB@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-db
