[R-sig-DB] Improving DBI

Kirill Müller k|r|||@mue||er @end|ng |rom |vt@b@ug@ethz@ch
Mon Jan 4 22:03:43 CET 2016


On 04.01.2016 21:42, Paul Gilbert wrote:
>
>
> On 01/04/2016 08:50 AM, Kirill Müller wrote:
>> 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.

Thanks, Paul, I think I got your point. I have opened a GitHub issue for 
further discussion: https://github.com/rstats-db/DBI/issues/72. E-mail 
is fine, too.


-Kirill




More information about the R-sig-DB mailing list