[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