Merge branch 'release/0.4' into production

.Rbuildignore

@@ -16,5 +16,4 @@ inst\/doc\/DBI\.b..$
 ^\.Rproj\.user$
 ^\.travis\.yml$
 ^cran-comments\.md$
-^NEWS\.md$
 ^revdep$

.travis.yml

@@ -1,6 +1,19 @@
+# R for travis: see documentation at https://docs.travis-ci.com/user/languages/r
+
 language: R
-cache: packages
 sudo: false
+cache: packages
+r:
+  - oldrel
+  - release
+  - devel
+
+r_packages: covr
 
 after_success:
   - Rscript -e 'covr::codecov()'
+
+notifications:
+  email:
+    on_success: change
+    on_failure: change

DESCRIPTION

@@ -1,8 +1,8 @@
 Package: DBI
-Version: 0.3.1.9010
+Version: 0.4
 Date: 2016-04-30
 Title: R Database Interface
-Description: A database interface (DBI) definition for communication
+Description: A database interface definition for communication
     between R and relational database management systems.  All
     classes in this package are virtual and need to be extended by
     the various R/DBMS implementations.

NEWS.md

@@ -1,12 +1,4 @@
-# DBI 0.3.1.9010 (2016-04-30)
-
-- The default implementation for `dbDataType()` (powered by `dbiDataType()`) now also supports `difftime` and `AsIs` objects and lists of `raw` (#70).
-- The `ANSI` dummy driver does not provide its own implementation of `dbDataType()` anymore, this removes the necessity to update many downstream packages.
-- Fix CRAN check.
-- Fix inteface for `sqlCreateTable()`.
-
-
-# DBI 0.3.1.9009 (2016-04-19)
+# DBI 0.4 (2016-04-30)
 
 * New package maintainer: Kirill Müller.
 
@@ -17,6 +9,9 @@
 
 * `dbDataType()` and `dbQuoteString()` are now properly exported.
 
+* The default implementation for `dbDataType()` (powered by `dbiDataType()`) now
+  also supports `difftime` and `AsIs` objects and lists of `raw` (#70).
+
 * Default `dbGetQuery()` method now always calls `dbFetch()`, in a `tryCatch()`
   block.
 

R/deprecated.R

@@ -210,7 +210,7 @@ setGeneric("dbCallProc",
 #' @keywords internal
 dbGetDBIVersion <- function() {
   .Deprecated("packageVersion('DBI')")
-  packageVersion("DBI")
+  utils::packageVersion("DBI")
 }
 
 #' Call an SQL stored procedure

R/rownames.R

@@ -40,7 +40,7 @@ sqlRownamesToColumn <- function(df, row.names = NA) {
     return(df)
   }
 
-  rn <- setNames(list(row.names(df)), name)
+  rn <- stats::setNames(list(row.names(df)), name)
 
   df <- c(rn, df)
   class(df) <- "data.frame"

README.md

@@ -2,7 +2,7 @@
 
 [![Build Status](https://travis-ci.org/rstats-db/DBI.png?branch=master)](https://travis-ci.org/rstats-db/DBI) [![Coverage Status](https://img.shields.io/codecov/c/github/rstats-db/DBI/master.svg)](https://codecov.io/github/rstats-db/DBI?branch=master)
 
-The DBI package defines a common interface between the R and database management systems (DBMS).  The interface defines a small set of classes and methods similar in spirit to Perl's [DBI](http://dbi.perl.org/), Java's [JDBC](http://www.oracle.com/technetwork/java/javase/jdbc/index.html), Python's [DB-API](http://www.python.org/dev/peps/pep-0249/), and Microsoft's [ODBC]((http://en.wikipedia.org/wiki/ODBC)). It defines a set of classes and methods defines what operations are possible and how they are performed:  
+The DBI package defines a common interface between the R and database management systems (DBMS).  The interface defines a small set of classes and methods similar in spirit to Perl's [DBI](http://dbi.perl.org/), Java's [JDBC](http://www.oracle.com/technetwork/java/javase/jdbc/index.html), Python's [DB-API](http://www.python.org/dev/peps/pep-0249/), and Microsoft's [ODBC](http://en.wikipedia.org/wiki/ODBC). It defines a set of classes and methods defines what operations are possible and how they are performed:
 
 * connect/disconnect to the DBMS
 * create and execute statements in the DBMS
@@ -70,7 +70,7 @@ All classes are _virtual_: they cannot be instantiated directly and instead must
 
 The following history of DBI was contributed by David James, the driving force behind the development of DBI, and many of the packages that implement it.
 
-The idea/work of interfacing S (originally S3 and S4) to RDBMS goes back to the mid- and late 1990's in Bell Labs. The first toy interface I did was to implement John Chamber's early concept of "Data Management in S" (1991). The implementation followed that interface pretty closely and immediately showed some of the limitations when dealing with very large databases; if my memory serves me, the issue was the instance-based of the language back then, e.g., if you attached an RDBMS to the `search()` path and then needed to resolve a symbol "foo", you effectively had to bring all the objects in the database to check their mode/class, i.e., the instance object had the metadata in itself as attributes. The experiment showed that the S3 implementation of "data management" was not really suitable to large external RDBMS (probably it was never intended to do that anyway). (Note however, that since then, John and Duncan Temple Lang generalized the data management in S4 a lot, including Duncan's implementation in his [RObjectTables](http://www.omegahat.org/RObjectTables/) package where he considered a lot of synchronization/caching issues relevant to DBI and, more generally, to most external interfaces).
+The idea/work of interfacing S (originally S3 and S4) to RDBMS goes back to the mid- and late 1990's in Bell Labs. The first toy interface I did was to implement John Chamber's early concept of "Data Management in S" (1991). The implementation followed that interface pretty closely and immediately showed some of the limitations when dealing with very large databases; if my memory serves me, the issue was the instance-based of the language back then, e.g., if you attached an RDBMS to the `search()` path and then needed to resolve a symbol "foo", you effectively had to bring all the objects in the database to check their mode/class, i.e., the instance object had the metadata in itself as attributes. The experiment showed that the S3 implementation of "data management" was not really suitable to large external RDBMS (probably it was never intended to do that anyway). (Note however, that since then, John and Duncan Temple Lang generalized the data management in S4 a lot, including Duncan's implementation in his RObjectTables package where he considered a lot of synchronization/caching issues relevant to DBI and, more generally, to most external interfaces).
 
 Back then we were working very closely with Lucent's microelectronics manufacturing --- our colleagues there had huge Oracle (mostly) databases that we needed to constantly query via [SQL*Plus](http://en.wikipedia.org/wiki/SQL*Plus). My colleague Jake Luciani was developing advanced applications in C and SQL, and the two of us came up with the first implementation of S3 directly connecting with Oracle.  What I remember is that the Linux [PRO*C](http://en.wikipedia.org/wiki/Pro*C) pre-compiler (that embedded SQL in C code) was very buggy --- we spent a lot of time looking for workarounds and tricks until we got the C interface running.  At the time, other projects within Bell Labs began using MySQL, and we moved to MySQL (with the help of Doug Bates' student Saikat DebRoy, then a summer intern) with no intentions of looking back at the very difficult Oracle interface.  It was at this time that I moved all the code from S3 methods to S4 classes and methods and begun reaching out to the S/R community for suggestions, ideas, etc.  All (most) of this work was on Bell Labs versions of S3 and S4, but I made sure it worked with S-Plus. At some point around 2000 (I don't remember exactly when), I ported all the code to R regressing to S3 methods, and later on (once S4 classes and methods were available in R) I re-implemented everything back to S4 classes and methods in R (a painful back-and-forth). It was at this point that I decided to drop S-Plus altogether.  Around that time, I came across a very early implementation of SQLite and I was quite interested and thought it was a very nice RDBMS that could be used for all kinds of experimentation, etc., so it was pretty easy to implement on top of the DBI.
 

cran-comments.md

@@ -1,11 +1,31 @@
-This is a patch release to fix two very minor problems (failed to export generic, used wrong method in default implementation of dbGetQuery).
+## Test environments
+* ubuntu 15.10 (local install), R 3.2.5
+* ubuntu 12.04 (on travis-ci), R 3.2.5
+* win-builder (devel)
 
-The following notes were generated across my local OS X install, ubuntu running on travis-ci and win builder (devel and release):
+## R CMD check results
 
-* checking CRAN incoming feasibility ... NOTE
-  Possibly mis-spelled words in DESCRIPTION:
-  DBI (8:36)
+0 errors | 0 warnings | 2 notes
+
+New maintainer:
+  Kirill Müller <[email protected]>
+Old maintainer(s):
+  Hadley Wickham <[email protected]>
+
+
+Found the following apparent S3 methods exported but not registered:
+  print.list.pairs
+
+- Hadley agrees that I act as maintainer: https://github.com/rstats-db/DBI/commit/278f233c15ea629db8cc9ccd156d236d0a815cdd#commitcomment-16886895
+
+- print.list.pairs() has been deprecated and will be removed soon.
+
+
+## Reverse dependencies
+
+* I have run R CMD check on the 61 downstream dependencies.
+  (Summary at https://github.com/rstats-db/DBI/tree/0066ef1d03afc0c0caaf2436fa898755a2dba89f/revdep). 
 
-  These are correctly spelled.
+* There were failures and packages I could not install. For those packages that I could install, the DBI changes only seemed to trigger a regression in RMySQL, which will be investigated.
 
-I did not run R CMD check on downstream dependencies of DBI because the change is tiny.
+* All revdep maintainers were notified of the release on 2016-03-30.