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@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
