On 09/05/2014 11:39 AM, MacQueen, Don wrote:
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.
I think it would generally be the case that an end user would like their queries to throw errors as reported by the database. But for a programming API one might like a bit finer control. For example, in the case of an error in the SQL statement it can be useful if the database error is reported (from dbGetException()), and also some details about objects used by the function to construct the query are reported. In the case of an expired con a stop() from the DBI function can be passed directly to the user and the extra information, which would just hide the real error message, can be skipped. Admittedly, it is difficult to know where the distinction should be between FALSE and stop(). But the difference between an end users' needs and the needs of a programming API is really the reason I think there is a need for two sets of programs.
I personally think of DBI as defining the programming API, and packages like RMySQl, RSQLite, etc, implementing the programming API but, in fact, these are being used by end users directly to submit queries and write batch scripts, so there are two sets of needs. But as I've said before, in the end I can work with it either way.
Paul
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
_______________________________________________ R-sig-DB mailing list -- R Special Interest Group R-sig-DB@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-db
