Separate packages for handling DB connections and SQL?

[krlmlr]

Quoting Paul Gilbert's post to R-sig-DB:

[Splitting DBI] 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.

If such a split is implemented, probably currently only the Result class (with all its methods) and the Connection methods dbSendQuery() and dbGetQuery() would end up in the DBIsql package. I'm not sure what this means for backward compatibility. An advantage would be that such a DBIsql package could host an array of other methods -- creating indexes, views, ... .

A way around the reverse dependency nightmare outlined by Paul is to design DBI around the open/closed principle -- open for extension, closed for modification. This requires very careful design, but looks doable.

[hannes]

And then the result class is only used once to fetch it to a data frame... Also, do NoSQL systems not support some sort of query language? The result object is already opaque w.r.t. its contents.

[krlmlr]

• Separate tests into no-SQL and SQL parts
• Specify extension strategy for DBI

[krlmlr]

SQL is wired fairly deeply into DBI and DBItest.