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
_______________________________________________
R-sig-DB mailing list -- R Special Interest Group
R-sig-DB@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-db
