Improving DBI

Paul

Thanks for your feedback. I'm not sure we want two separate packages for
DBI, but we can surely split the DBI specification as to make the "SQL"
part optional.
For my use it does not make much difference, I can just import what I 
need from DBI. However, it might make a lot of sense if you ever want to 
standardize in layers, for example, if you ever wanted NoSQL to be a 
possible replacement for SQL.

There are different reasons for wanting separate packages, but the 
important one in my mind may not be the one you are thinking about: The 
classes, and the generic methods dbConnect, and dbDisconnect should all 
be extremely stable. On the other hand, the SQL part is likely to go 
through some changes. For sake of discussion let me call the two 
packages DBIclasses and DBIsql. If you make a change in DBIsql my 
packages TSsdmx, TSmisc, and some others, will not be in the upstream 
dependencies, and do not need to be tested for a CRAN submission of 
DBIsql. If DBIclasses and DBIsql are in the one package, DBI, then these 
packages do need to be checked (not just by me but also by you if you 
make an API change and intend to submit to CRAN). These packages in turn 
have a large number of dependencies which can change from time to time 
on their own. Thus things may be broken for reasons having nothing to do 
with your changes, and are beyond your control. Then the CRAN checks 
will fail and your submission will be rejected, or at least require 
considerable additional work. So, it is advisable to avoid having 
dependencies that really can be avoided.
This may mean that more legible error messages are
returned for virtual methods that are not implemented, or at least that
the meaning of the current error messages ("unable to find an inherited
method...") is well communicated. The "kludge" example is in fact a
proper implementation of the corresponding DBI subset :-)
Yes, I hope so. It was only a kludge in the sense that these are not in 
the package I am wrapping, as they are in other packages I wrap like 
RMySQL that use DBI
You could then use the DBI test suite (=specification) just the same,
simply don't test the "SQL" part of DBI. Would that help?
Yes, I think that might be useful.

Best,
Paul

Best regards

Kirill

On 03.01.2016 23:32, Paul Gilbert wrote:
Kirill

TSdbi implements a time series specific API on top of DBI. Some of my
TSdbi packages use DBI in what you might consider the traditional way
(TSMySQL, TSPostgreSQL, TSSQLite). TSodbc fudges a bit so it can use
RODBC, doing some of what would be needed in RODBCDBI. But several of
my packages interface to non-SQL databases and use only the DBI class
definitions and a couple of essential generic methods (possibly just
dbConnect and dbDisconnect). This includes packages TSsdmx, TSmisc,
TSjson, TSfame, TSbbg, some on CRAN and some not. These packages
interface to time series data from a variety of sources, many over the
Internet. They all just wrap other packages in an attempt to
standardize the API.

I think it would be nice if you can separate the DBI classes and the
few essential generic methods into a different package from the more
SQL specific parts of DBI. (I have taken this approach with my
packages TSdbi and TSsql.)

To get a sense of how I use this in the non-SQL context you might look
at package TSsdmx, in which the R code has

####### some kludges to make this look like DBI. ######
#for this require("DBI") ; require("RJSDMX")

setClass("sdmxDriver", contains=c("DBIDriver"))

setClass("sdmxConnection", contains=c("DBIConnection", "sdmxDriver"),
   slots=c(dbname="character") )

setMethod("dbConnect", signature(drv="sdmxDriver"),
     definition=function(drv, dbname, ...)
         new("sdmxConnection", dbname=dbname))

# this does nothing but prevent errors if it is called.
setMethod("dbDisconnect", signature(conn="sdmxConnection"),
     definition=function(conn,...) TRUE)

#######     end kludges   ######

Best of luck with your proposal and project.

Happy New Year,
Paul

On 12/30/2015 08:59 PM, Kirill M?ller wrote:
Hi

I have prepared a proposal for improving DBI, and three backends to
open-source databases: http://bit.ly/1QZNNrC (current version),
http://bit.ly/1Uhn1ZC (version at the time of writing). Among other
things, I plan to improve support for data types, parametrized queries,
and database schemas. Ultimately, DBI will be formally specified by a
test suite and a written description.

Before submitting it to the R Consortium, I'd be glad to receive further
input. Are there other design issues that need to be addressed? Other
points I have missed? Issues you might want to see resolved as part of
this project? See also the GitHub issue trackers for DBI [1] (which also
contains the design discussion [2]), RMySQL [3], RPostgres [4] and
RSQLite [5].

Please note that the deadline for submitting the proposal is already
January 10. Thank you for your attention.

Best regards

Kirill

[1] https://github.com/rstats-db/DBI/issues
[2]
https://github.com/rstats-db/DBI/issues?q=is%3Aopen+is%3Aissue+label%3Aaction%3Adesign

[3] https://github.com/rstats-db/RMySQL/issues
[4] https://github.com/rstats-db/RPostgres/issues
[5] https://github.com/rstats-db/RSQLite/issues

_______________________________________________
R-sig-DB mailing list -- R Special Interest Group
R-sig-DB at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-db

Improving DBI

Thread (4 messages)