[R-sig-DB] Improving DBI

[Kirill Müller]

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. 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 :-)

You could then use the DBI test suite (=specification) just the same, 
simply don't test the "SQL" part of DBI. Would that help?


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 using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-db