[R-sig-DB] SQL generics
Paul Gilbert
pg||bert902 @end|ng |rom gm@||@com
Wed Oct 23 18:09:06 CEST 2013
On 13-10-23 11:31 AM, Hadley Wickham wrote:
>> I would like to echo David's point even more strongly. Only a few of the
>> packages I have that use DBI actually have an SQL backend. The others really
>> only use part of the class structure and methods: DBIConnection, DBIDriver,
>> dbDisconnect. They use DBI so that I can present an API that is consistent
>> with the SQL based packages.
>
> Good point. What packages are those?
TShistQuote, TSgetSymbol, TSxls, TSzip, TSjson and TSdbi. The last has
my own class and generics and was recently split into TSdbi and TSsql
partly because of the non-use of SQL in several dependent packages and
partly because they export to two different audiences (end users need
the generics so I need Depend on TSdbi while other packages can Import
TSsql). It is hard to export to two audiences in one package without
using the now outlawed :::. Also, TScompare and TSdata only use SQL
indirectly, they call other packages that use it.
TSMySQL, TSPostgresql, TSSQLLite, TSodbc, and TSOracle (on R-forge but
not CRAN) are the only ones that really use SQL. TSsql is a common
utility package for these. (Despite comments on a related thread, if you
use standard SQL and avoid vendor specific enhancements you can do a lot
that works on multiple engines, even select statements. But I do have
the advantage that end users never actually construct SQL statements.)
Paul
>
>> I would be happy to see the upper part of the classes and methods moved
>> entirely into a separate package from all the SQL. (And it would make my
>> life easier if this part remained really stable once it is set.)
>
> I think the unfortunate reality of R package development is that
> currently splitting things up into many small packages actually
> creates more headaches that having packages that do slightly too much.
>
> Hadley
>
More information about the R-sig-DB
mailing list