DBI/0000755000176200001440000000000013070027747010657 5ustar liggesusersDBI/inst/0000755000176200001440000000000013070016501011616 5ustar liggesusersDBI/inst/doc/0000755000176200001440000000000013070016501012363 5ustar liggesusersDBI/inst/doc/backend.Rmd0000644000176200001440000002343413070016501014424 0ustar liggesusers --- title: "Implementing a new backend" author: "Hadley Wickham" date: "`r Sys.Date()`" output: rmarkdown::html_vignette vignette: > %\VignetteIndexEntry{Implementing a new backend} %\VignetteEngine{knitr::rmarkdown} \usepackage[utf8]{inputenc} --- ```{r, echo = FALSE} library(DBI) knitr::opts_chunk$set(collapse = TRUE, comment = "#>") ``` The goal of this document is to help you implement a new backend for DBI. If you are writing a package that connects a database to R, I highly recommend that you make it DBI compatible because it makes your life easier by spelling out exactly what you need to do. The consistent interface provided by DBI makes it easier for you to implement the package (because you have fewer arbitrary choices to make), and easier for your users (because it follows a familiar pattern). In addition, the `DBItest` package provides test cases which you can easily incorporate in your package. I'll illustrate the process using a fictional database called Kazam. ## Getting started Start by creating a package. It's up to you what to call the package, but following the existing pattern of `RSQLite`, `RMySQL`, `RPostgres` and `ROracle` will make it easier for people to find it. For this example, I'll call my package `RKazam`. In your `DESCRIPTION`, make sure to include: ```yaml Imports: DBI (>= 0.3.0), methods Suggests: DBItest, testthat ``` Importing `DBI` is fine, because your users are not supposed to *attach* your package anyway; the preferred method is to attach `DBI` and use explicit qualification via `::` to access the driver in your package (which needs to be done only once). ## Testing Why testing at this early stage? Because testing should be an integral part of the software development cycle. Test right from the start, add automated tests as you go, finish faster (because tests are automated) while maintaining superb code quality (because tests also check corner cases that you might not be aware of). Don't worry: if some test cases are difficult or impossible to satisfy, or take too long to run, you can just turn them off. Take the time now to head over to the `DBItest` vignette. You will find a vast amount of ready-to-use test cases that will help you in the process of implementing your new DBI backend. ```r vignette("test", package = "DBItest") ``` Add custom tests that are not covered by `DBItest` at your discretion, or enhance `DBItest` and file a pull request if the test is generic enough to be useful for many DBI backends. ## Driver Start by making a driver class which inherits from `DBIDriver`. This class doesn't need to do anything, it's just used to dispatch other generics to the right method. Users don't need to know about this, so you can remove it from the default help listing with `@keywords internal`: ```{r} #' Driver for Kazam database. #' #' @keywords internal #' @export #' @import DBI #' @import methods setClass("KazamDriver", contains = "DBIDriver") ``` The driver class was more important in older versions of DBI, so you should also provide a dummy `dbUnloadDriver()` method. ```{r} #' @export #' @rdname Kazam-class setMethod("dbUnloadDriver", "KazamDriver", function(drv, ...) { TRUE }) ``` If your package needs global setup or tear down, do this in the `.onLoad()` and `.onUnload()` functions. You might also want to add a show method so the object prints nicely: ```{r} setMethod("show", "KazamDriver", function(object) { cat("\n") }) ``` Next create `Kazam()` which instantiates this class. ```{r} #' @export Kazam <- function() { new("KazamDriver") } Kazam() ``` ## Connection Next create a connection class that inherits from `DBIConnection`. This should store all the information needed to connect to the database. If you're talking to a C api, this will include a slot that holds an external pointer. ```{r} #' Kazam connection class. #' #' @export #' @keywords internal setClass("KazamConnection", contains = "DBIConnection", slots = list( host = "character", username = "character", # and so on ptr = "externalptr" ) ) ``` Now you have some of the boilerplate out of the way, you can start work on the connection. The most important method here is `dbConnect()` which allows you to connect to a specified instance of the database. Note the use of `@rdname Kazam`. This ensures that `Kazam()` and the connect method are documented together. ```{r} #' @param drv An object created by \code{Kazam()} #' @rdname Kazam #' @export #' @examples #' \dontrun{ #' db <- dbConnect(RKazam::Kazam()) #' dbWriteTable(db, "mtcars", mtcars) #' dbGetQuery(db, "SELECT * FROM mtcars WHERE cyl == 4") #' } setMethod("dbConnect", "KazamDriver", function(drv, ...) { # ... new("KazamConnection", host = host, ...) }) ``` * Replace `...` with the arguments needed to connect to your database. You'll always need to include `...` in the arguments, even if you don't use it, for compatibility with the generic. * This is likely to be where people first come for help, so the examples should show how to connect to the database, and how to query it. (Obviously these examples won't work yet.) Ideally, include examples that can be run right away (perhaps relying on a publicly hosted database), but failing that surround in `\dontrun{}` so people can at least see the code. Next, implement `show()` and `dbDisconnect()` methods. ## Results Finally, you're ready to implement the meat of the system: fetching results of a query into a data frame. First define a results class: ```{r} #' Kazam results class. #' #' @keywords internal #' @export setClass("KazamResult", contains = "DBIResult", slots = list(ptr = "externalptr") ) ``` Then write a `dbSendQuery()` method. This takes a connection and SQL string as arguments, and returns a result object. Again `...` is needed for compatibility with the generic, but you can add other arguments if you need them. ```{r} #' Send a query to Kazam. #' #' @export #' @examples #' # This is another good place to put examples setMethod("dbSendQuery", "KazamConnection", function(conn, statement, ...) { # some code new("KazamResult", ...) }) ``` Next, implement `dbClearResult()`, which should close the result set and free all resources associated with it: ```{r} #' @export setMethod("dbClearResult", "KazamResult", function(res, ...) { # free resources TRUE }) ``` The hardest part of every DBI package is writing the `dbFetch()` method. This needs to take a result set and (optionally) number of records to return, and create a dataframe. Mapping R's data types to those of your database may require a custom implementation of the `dbDataType()` method for your connection class: ```{r} #' Retrieve records from Kazam query #' @export setMethod("dbFetch", "KazamResult", function(res, n = -1, ...) { ... }) # (optionally) #' Find the database data type associated with an R object #' @export setMethod("dbDataType", "KazamConnection", function(dbObj, obj, ...) { ... }) ``` Next, implement `dbHasCompleted()` which should return a `logical` indicating if there are any rows remaining to be fetched. ```{r} #' @export setMethod("dbHasCompleted", "KazamResult", function(res, ...) { }) ``` With these four methods in place, you can now use the default `dbGetQuery()` to send a query to the database, retrieve results if available and then clean up. Spend some time now making sure this works with an existing database, or relax and let the `DBItest` package do the work for you. ## SQL methods You're now on the home stretch, and can make your wrapper substantially more useful by implementing methods that wrap around variations in SQL across databases: * `dbQuoteString()` and `dbQuoteIdentifer()` are used to safely quote strings and identifiers to avoid SQL injection attacks. Note that the former must be vectorized, but not the latter. * `dbWriteTable()` creates a database table given an R dataframe. I'd recommend using the functions prefixed with `sql` in this package to generate the SQL. These functions are still a work in progress so please let me know if you have problems. * `dbReadTable()`: a simple wrapper around `SELECT * FROM table`. Use `dbQuoteIdentifer()` to safely quote the table name and prevent mismatches between the names allowed by R and the database. * `dbListTables()` and `dbExistsTable()` let you determine what tables are available. If not provided by your database's API, you may need to generate sql that inspects the system tables. * `dbListFields()` shows which fields are available in a given table. * `dbRemoveTable()` wraps around `DROP TABLE`. Start with `SQL::sqlTableDrop()`. * `dbBegin()`, `dbCommit()` and `dbRollback()`: implement these three functions to provide basic transaction support. This functionality is currently not tested in the `DBItest` package. ## Metadata methods There are a lot of extra metadata methods for result sets (and one for the connection) that you might want to implement. They are described in the following. * `dbIsValid()` returns if a connection or a result set is open (`TRUE`) or closed (`FALSE`). All further methods in this section are valid for result sets only. * `dbGetStatement()` returns the issued query as a character value. * `dbColumnInfo()` lists the names and types of the result set's columns. * `dbGetRowCount()` and `dbGetRowsAffected()` returns the number of rows returned or altered in a `SELECT` or `INSERT`/`UPDATE` query, respectively. * `dbBind()` allows using parametrised queries. Take a look at `sqlInterpolate()` and `sqlParseVariables()` if your SQL engine doesn't offer native parametrised queries. ## Full DBI compliance By now, your package should implement all methods defined in the DBI specification. If you want to walk the extra mile, offer a read-only mode that allows your users to be sure that their valuable data doesn't get destroyed inadvertently. DBI/inst/doc/spec.html0000644000176200001440000413745213070016501014223 0ustar liggesusers DBI specification

DBI: R Database Interface

DBI defines an interface 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 (so-called DBI backends).

Definition

A DBI backend is an R package, which should import the DBI and methods packages. For better or worse, the names of many existing backends start with ‘R’, e.g., RSQLite, RMySQL, RSQLServer; it is up to the backend author to adopt this convention or not.

DBI classes and methods

A backend defines three classes, which are subclasses of DBIDriver, DBIConnection, and DBIResult. The backend provides implementation for all methods of these base classes that are defined but not implemented by DBI. All methods have an ellipsis ... in their formals.

Construction of the DBIDriver object

The backend must support creation of an instance of its DBIDriver subclass with a constructor function. By default, its name is the package name without the leading ‘R’ (if it exists), e.g., SQLite for the RSQLite package. However, backend authors may choose a different name. The constructor must be exported, and it must be a function that is callable without arguments. DBI recommends to define a constructor with an empty argument list.

Examples 

RSQLite::SQLite()

Determine the SQL data type of an object

This section describes the behavior of the following method: 

dbDataType(dbObj, obj, ...)

Description

Returns an SQL string that describes the SQL data type to be used for an object. The default implementation of this generic determines the SQL type of an R object according to the SQL 92 specification, which may serve as a starting point for driver implementations. DBI also provides an implementation for data.frame which will return a character vector giving the type for each column in the dataframe.

Arguments

dbObj

A object inheriting from DBIDriver or DBIConnection

obj

An R object whose SQL type we want to determine.

...

Other arguments passed on to methods.

Details

The data types supported by databases are different than the data types in R, but the mapping between the primitive types is straightforward:

  • Any of the many fixed and varying length character types are mapped to character vectors

  • Fixed-precision (non-IEEE) numbers are mapped into either numeric or integer vectors.

Notice that many DBMS do not follow IEEE arithmetic, so there are potential problems with under/overflows and loss of precision.

Value

dbDataType() returns the SQL type that corresponds to the obj argument as a non-empty character string. For data frames, a character vector with one element per column is returned. An error is raised for invalid values for the obj argument such as a NULL value.

Specification

The backend can override the dbDataType() generic for its driver class.

This generic expects an arbitrary object as second argument. To query the values returned by the default implementation, run example(dbDataType, package = "DBI"). If the backend needs to override this generic, it must accept all basic R data types as its second argument, namely logical, integer, numeric, character, dates (see Dates), date-time (see DateTimeClasses), and difftime. It also must accept lists of raw vectors and map them to the BLOB (binary large object) data type, unless the omit_blob_tests tweak is set to TRUE. As-is objects (i.e., wrapped by I()) must be supported and return the same results as their unwrapped counterparts. The SQL data type for factor and ordered is the same as for character. The behavior for other object types is not specified.

All data types returned by dbDataType() are usable in an SQL statement of the form "CREATE TABLE test (a ...)".

Examples 

dbDataType(ANSI(), 1:5)
dbDataType(ANSI(), 1)
dbDataType(ANSI(), TRUE)
dbDataType(ANSI(), Sys.Date())
dbDataType(ANSI(), Sys.time())
dbDataType(ANSI(), Sys.time() - as.POSIXct(Sys.Date()))
dbDataType(ANSI(), c("x", "abc"))
dbDataType(ANSI(), list(raw(10), raw(20)))
dbDataType(ANSI(), I(3))

dbDataType(ANSI(), iris)

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbDataType(con, 1:5)
dbDataType(con, 1)
dbDataType(con, TRUE)
dbDataType(con, Sys.Date())
dbDataType(con, Sys.time())
dbDataType(con, Sys.time() - as.POSIXct(Sys.Date()))
dbDataType(con, c("x", "abc"))
dbDataType(con, list(raw(10), raw(20)))
dbDataType(con, I(3))

dbDataType(con, iris)

dbDisconnect(con)

Create a connection to a DBMS

This section describes the behavior of the following method: 

dbConnect(drv, ...)

Description

Connect to a DBMS going through the appropriate authentication procedure. Some implementations may allow you to have multiple connections open, so you may invoke this function repeatedly assigning its output to different objects. The authentication mechanism is left unspecified, so check the documentation of individual drivers for details.

Arguments

drv

an object that inherits from DBIDriver, or an existing DBIConnection object (in order to clone an existing connection).

...

authentication arguments needed by the DBMS instance; these typically include user, password, host, port, dbname, etc. For details see the appropriate DBIDriver.

Value

dbConnect() returns an S4 object that inherits from DBIConnection. This object is used to communicate with the database engine.

Specification

DBI recommends using the following argument names for authentication parameters, with NULL default:

  • user for the user name (default: current user)

  • password for the password

  • host for the host name (default: local connection)

  • port for the port number (default: local connection)

  • dbname for the name of the database on the host, or the database file name

The defaults should provide reasonable behavior, in particular a local connection for host = NULL. For some DBMS (e.g., PostgreSQL), this is different to a TCP/IP connection to localhost.

Examples 

# SQLite only needs a path to the database. (Here, ":memory:" is a special
# path that creates an in-memory database.) Other database drivers
# will require more details (like user, password, host, port, etc.)
con <- dbConnect(RSQLite::SQLite(), ":memory:")
con

dbListTables(con)

dbDisconnect(con)

Disconnect (close) a connection

This section describes the behavior of the following method: 

dbDisconnect(conn, ...)

Description

This closes the connection, discards all pending work, and frees resources (e.g., memory, sockets).

Arguments

conn

A DBIConnection object, as returned by dbConnect().

...

Other parameters passed on to methods.

Value

dbDisconnect() returns TRUE, invisibly.

Specification

A warning is issued on garbage collection when a connection has been released without calling dbDisconnect(). A warning is issued immediately when calling dbDisconnect() on an already disconnected connection.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")
dbDisconnect(con)

Execute a query on a given database connection

This section describes the behavior of the following method: 

dbSendQuery(conn, statement, ...)

Description

The dbSendQuery() method only submits and synchronously executes the SQL query to the database engine. It does not extract any records — for that you need to use the dbFetch() method, and then you must call dbClearResult() when you finish fetching the records you need. For interactive use, you should almost always prefer dbGetQuery().

Arguments

conn

A DBIConnection object, as returned by dbConnect().

statement

a character string containing SQL.

...

Other parameters passed on to methods.

Details

This method is for SELECT queries only. Some backends may support data manipulation queries through this method for compatibility reasons. However, callers are strongly encouraged to use dbSendStatement() for data manipulation statements.

The query is submitted to the database server and the DBMS executes it, possibly generating vast amounts of data. Where these data live is driver-specific: some drivers may choose to leave the output on the server and transfer them piecemeal to R, others may transfer all the data to the client – but not necessarily to the memory that R manages. See individual drivers' dbSendQuery() documentation for details.

Value

dbSendQuery() returns an S4 object that inherits from DBIResult. The result set can be used with dbFetch() to extract records. Once you have finished using a result, make sure to clear it with dbClearResult(). An error is raised when issuing a query over a closed or invalid connection, if the syntax of the query is invalid, or if the query is not a non-NA string.

Specification

No warnings occur under normal conditions. When done, the DBIResult object must be cleared with a call to dbClearResult(). Failure to clear the result set leads to a warning when the connection is closed.

If the backend supports only one open result set per connection, issuing a second query invalidates an already open result set and raises a warning. The newly opened result set is valid and must be cleared with dbClearResult().

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars)
rs <- dbSendQuery(con, "SELECT * FROM mtcars WHERE cyl = 4;")
dbFetch(rs)
dbClearResult(rs)

dbDisconnect(con)

Fetch records from a previously executed query

This section describes the behavior of the following methods: 

dbFetch(res, n = -1, ...)

fetch(res, n = -1, ...)

Description

Fetch the next n elements (rows) from the result set and return them as a data.frame.

Arguments

res

An object inheriting from DBIResult, created by dbSendQuery().

n

maximum number of records to retrieve per fetch. Use n = -1 or n = Inf to retrieve all pending records. Some implementations may recognize other special values.

...

Other arguments passed on to methods.

Details

fetch() is provided for compatibility with older DBI clients - for all new code you are strongly encouraged to use dbFetch(). The default implementation for dbFetch() calls fetch() so that it is compatible with existing code. Modern backends should implement for dbFetch() only.

Value

dbFetch() always returns a data.frame with as many rows as records were fetched and as many columns as fields in the result set, even if the result is a single value or has one or zero rows. An attempt to fetch from a closed result set raises an error. If the n argument is not an atomic whole number greater or equal to -1 or Inf, an error is raised, but a subsequent call to dbFetch() with proper n argument succeeds. Calling dbFetch() on a result set from a data manipulation query created by dbSendStatement() can be fetched and return an empty data frame, with a warning.

Specification

Fetching multi-row queries with one or more columns be default returns the entire result. Multi-row queries can also be fetched progressively by passing a whole number (integer or numeric) as the n argument. A value of Inf for the n argument is supported and also returns the full result. If more rows than available are fetched, the result is returned in full without warning. If fewer rows than requested are returned, further fetches will return a data frame with zero rows. If zero rows are fetched, the columns of the data frame are still fully typed. Fetching fewer rows than available is permitted, no warning is issued when clearing the result set.

The column types of the returned data frame depend on the data returned:

  • integer for integer values between -2^31 and 2^31 - 1

  • numeric for numbers with a fractional component

  • logical for Boolean values (some backends may return an integer)

  • character for text

  • lists of raw for blobs (with NULL entries for SQL NULL values)

  • coercible using as.Date() for dates (also applies to the return value of the SQL function current_date)

  • coercible using hms::as.hms() for times (also applies to the return value of the SQL function current_time)

  • coercible using as.POSIXct() for timestamps (also applies to the return value of the SQL function current_timestamp)

  • NA for SQL NULL values

If dates and timestamps are supported by the backend, the following R types are used:

  • Date for dates (also applies to the return value of the SQL function current_date)

  • POSIXct for timestamps (also applies to the return value of the SQL function current_timestamp)

R has no built-in type with lossless support for the full range of 64-bit or larger integers. Here, the following rules apply:

  • Values are returned as numeric

  • Conversion to character always returns a lossless decimal representation of the data

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars)

# Fetch all results
rs <- dbSendQuery(con, "SELECT * FROM mtcars WHERE cyl = 4")
dbFetch(rs)
dbClearResult(rs)

# Fetch in chunks
rs <- dbSendQuery(con, "SELECT * FROM mtcars")
while (!dbHasCompleted(rs)) {
  chunk <- dbFetch(rs, 10)
  print(nrow(chunk))
}

dbClearResult(rs)
dbDisconnect(con)

Clear a result set

This section describes the behavior of the following method: 

dbClearResult(res, ...)

Description

Frees all resources (local and remote) associated with a result set. In some cases (e.g., very large result sets) this can be a critical step to avoid exhausting resources (memory, file descriptors, etc.)

Arguments

res

An object inheriting from DBIResult.

...

Other arguments passed on to methods.

Value

dbClearResult() returns TRUE, invisibly, for result sets obtained from both dbSendQuery() and dbSendStatement(). An attempt to close an already closed result set issues a warning in both cases.

Specification

dbClearResult() frees all resources associated with retrieving the result of a query or update operation. The DBI backend can expect a call to dbClearResult() for each dbSendQuery() or dbSendStatement() call.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

rs <- dbSendQuery(con, "SELECT 1")
print(dbFetch(rs))

dbClearResult(rs)
dbDisconnect(con)

Bind values to a parameterized/prepared statement

This section describes the behavior of the following method: 

dbBind(res, params, ...)

Description

For parametrized or prepared statements, the dbSendQuery() and dbSendStatement() functions can be called with statements that contain placeholders for values. The dbBind() function binds these placeholders to actual values, and is intended to be called on the result set before calling dbFetch() or dbGetRowsAffected().

Arguments

res

An object inheriting from DBIResult.

params

A list of bindings, named or unnamed.

...

Other arguments passed on to methods.

Details

DBI supports parametrized (or prepared) queries and statements via the dbBind() generic. Parametrized queries are different from normal queries in that they allow an arbitrary number of placeholders, which are later substituted by actual values. Parametrized queries (and statements) serve two purposes:

  • The same query can be executed more than once with different values. The DBMS may cache intermediate information for the query, such as the execution plan, and execute it faster.

  • Separation of query syntax and parameters protects against SQL injection.

The placeholder format is currently not specified by DBI; in the future, a uniform placeholder syntax may be supported. Consult the backend documentation for the supported formats. For automated testing, backend authors specify the placeholder syntax with the placeholder_pattern tweak. Known examples are:

  • ? (positional matching in order of appearance) in RMySQL and RSQLite

  • $1 (positional matching by index) in RPostgres and RSQLite

  • :name and $name (named matching) in RSQLite

Value

dbBind() returns the result set, invisibly, for queries issued by dbSendQuery() and also for data manipulation statements issued by dbSendStatement(). Calling dbBind() for a query without parameters raises an error. Binding too many or not enough values, or parameters with wrong names or unequal length, also raises an error. Calling dbBind() on a result set already cleared by dbClearResult() also raises an error.

Specification

DBI clients execute parametrized statements as follows:

  1. Call dbSendQuery() or dbSendStatement() with a query or statement that contains placeholders, store the returned DBIResult object in a variable. Mixing placeholders (in particular, named and unnamed ones) is not recommended. It is good practice to register a call to dbClearResult() via on.exit() right after calling dbSendQuery() or dbSendStatement() (see the last enumeration item).

  2. Construct a list with parameters that specify actual values for the placeholders. The list must be named or unnamed, depending on the kind of placeholders used. Named values are matched to named parameters, unnamed values are matched by position in the list of parameters. All elements in this list must have the same lengths and contain values supported by the backend; a data.frame is internally stored as such a list. The parameter list is passed to a call to dbBind() on the DBIResult object.

  3. Retrieve the data or the number of affected rows from the DBIResult object.

    • For queries issued by dbSendQuery(), call dbFetch().

    • For statements issued by dbSendStatements(), call dbGetRowsAffected(). (Execution begins immediately after the dbBind() call, the statement is processed entirely before the function returns.)

  4. Repeat 2. and 3. as necessary.

  5. Close the result set via dbClearResult().

The elements of the params argument do not need to be scalars, vectors of arbitrary length (including length 0) are supported. For queries, calling dbFetch() binding such parameters returns concatenated results, equivalent to binding and fetching for each set of values and connecting via rbind(). For data manipulation statements, dbGetRowsAffected() returns the total number of rows affected if binding non-scalar parameters. dbBind() also accepts repeated calls on the same result set for both queries and data manipulation statements, even if no results are fetched between calls to dbBind().

At least the following data types are accepted:

  • integer

  • numeric

  • logical for Boolean values (some backends may return an integer)

  • NA

  • character

  • Date

  • POSIXct timestamps

  • POSIXlt timestamps

  • lists of raw for blobs (with NULL entries for SQL NULL values)

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "iris", iris)

# Using the same query for different values
iris_result <- dbSendQuery(con, "SELECT * FROM iris WHERE [Petal.Width] > ?")
dbBind(iris_result, list(2.3))
dbFetch(iris_result)
dbBind(iris_result, list(3))
dbFetch(iris_result)
dbClearResult(iris_result)

# Executing the same statement with different values at once
iris_result <- dbSendStatement(con, "DELETE FROM iris WHERE [Species] = $species")
dbBind(iris_result, list(species = c("setosa", "versicolor", "unknown")))
dbGetRowsAffected(iris_result)
dbClearResult(iris_result)

nrow(dbReadTable(con, "iris"))

dbDisconnect(con)

Send query, retrieve results and then clear result set

This section describes the behavior of the following method: 

dbGetQuery(conn, statement, ...)

Description

Returns the result of a query as a data frame. dbGetQuery() comes with a default implementation (which should work with most backends) that calls dbSendQuery(), then dbFetch(), ensuring that the result is always free-d by dbClearResult().

Arguments

conn

A DBIConnection object, as returned by dbConnect().

statement

a character string containing SQL.

...

Other parameters passed on to methods.

Details

This method is for SELECT queries only. Some backends may support data manipulation statements through this method for compatibility reasons. However, callers are strongly advised to use dbExecute() for data manipulation statements.

Value

dbGetQuery() always returns a data.frame with as many rows as records were fetched and as many columns as fields in the result set, even if the result is a single value or has one or zero rows. An error is raised when issuing a query over a closed or invalid connection, if the syntax of the query is invalid, or if the query is not a non-NA string. If the n argument is not an atomic whole number greater or equal to -1 or Inf, an error is raised, but a subsequent call to dbGetQuery() with proper n argument succeeds.

Implementation notes

Subclasses should override this method only if they provide some sort of performance optimization.

Specification

Fetching multi-row queries with one or more columns be default returns the entire result. A value of Inf for the n argument is supported and also returns the full result. If more rows than available are fetched, the result is returned in full without warning. If zero rows are fetched, the columns of the data frame are still fully typed. Fetching fewer rows than available is permitted, no warning is issued.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars)
dbGetQuery(con, "SELECT * FROM mtcars")

dbDisconnect(con)

Execute a data manipulation statement on a given database connection

This section describes the behavior of the following method: 

dbSendStatement(conn, statement, ...)

Description

The dbSendStatement() method only submits and synchronously executes the SQL data manipulation statement (e.g., UPDATE, DELETE, INSERT INTO, DROP TABLE, ...) to the database engine. To query the number of affected rows, call dbGetRowsAffected() on the returned result object. You must also call dbClearResult() after that. For interactive use, you should almost always prefer dbExecute().

Arguments

conn

A DBIConnection object, as returned by dbConnect().

statement

a character string containing SQL.

...

Other parameters passed on to methods.

Details

dbSendStatement() comes with a default implementation that simply forwards to dbSendQuery(), to support backends that only implement the latter.

Value

dbSendStatement() returns an S4 object that inherits from DBIResult. The result set can be used with dbGetRowsAffected() to determine the number of rows affected by the query. Once you have finished using a result, make sure to clear it with dbClearResult(). An error is raised when issuing a statement over a closed or invalid connection, if the syntax of the statement is invalid, or if the statement is not a non-NA string.

Specification

No warnings occur under normal conditions. When done, the DBIResult object must be cleared with a call to dbClearResult(). Failure to clear the result set leads to a warning when the connection is closed. If the backend supports only one open result set per connection, issuing a second query invalidates an already open result set and raises a warning. The newly opened result set is valid and must be cleared with dbClearResult().

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "cars", head(cars, 3))
rs <- dbSendStatement(con,
  "INSERT INTO cars (speed, dist) VALUES (1, 1), (2, 2), (3, 3);")
dbHasCompleted(rs)
dbGetRowsAffected(rs)
dbClearResult(rs)
dbReadTable(con, "cars")   # there are now 6 rows

dbDisconnect(con)

Execute an update statement, query number of rows affected, and then close result set

This section describes the behavior of the following method: 

dbExecute(conn, statement, ...)

Description

Executes a statement and returns the number of rows affected. dbExecute() comes with a default implementation (which should work with most backends) that calls dbSendStatement(), then dbGetRowsAffected(), ensuring that the result is always free-d by dbClearResult().

Arguments

conn

A DBIConnection object, as returned by dbConnect().

statement

a character string containing SQL.

...

Other parameters passed on to methods.

Value

dbExecute() always returns a scalar numeric that specifies the number of rows affected by the statement. An error is raised when issuing a statement over a closed or invalid connection, if the syntax of the statement is invalid, or if the statement is not a non-NA string.

Implementation notes

Subclasses should override this method only if they provide some sort of performance optimization.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "cars", head(cars, 3))
dbReadTable(con, "cars")   # there are 3 rows
dbExecute(con,
  "INSERT INTO cars (speed, dist) VALUES (1, 1), (2, 2), (3, 3);")
dbReadTable(con, "cars")   # there are now 6 rows

dbDisconnect(con)

Quote literal strings

This section describes the behavior of the following method: 

dbQuoteString(conn, x, ...)

Description

Call this method to generate a string that is suitable for use in a query as a string literal, to make sure that you generate valid SQL and avoid SQL injection.

Arguments

conn

A subclass of DBIConnection, representing an active connection to an DBMS.

x

A character vector to quote as string.

...

Other arguments passed on to methods.

Value

dbQuoteString() returns an object that can be coerced to character, of the same length as the input. For an empty character vector this function returns a length-0 object.

When passing the returned object again to dbQuoteString() as x argument, it is returned unchanged. Passing objects of class SQL should also return them unchanged. (For backends it may be most convenient to return SQL objects to achieve this behavior, but this is not required.)

Specification

The returned expression can be used in a SELECT ... query, and for any scalar character x the value of dbGetQuery(paste0("SELECT ", dbQuoteString(x)))[[1]] must be identical to x, even if x contains spaces, quotes (single or double), backticks, or newlines (in any combination) or is itself the result of a dbQuoteString() call coerced back to character (even repeatedly). If x is NA, the result must merely satisfy is.na(). The strings "NA" or "NULL" are not treated specially.

NA should be translated to an unquoted SQL NULL, so that the query SELECT * FROM (SELECT 1) a WHERE ... IS NULL returns one row.

Examples 

# Quoting ensures that arbitrary input is safe for use in a query
name <- "Robert'); DROP TABLE Students;--"
dbQuoteString(ANSI(), name)

# NAs become NULL
dbQuoteString(ANSI(), c("x", NA))

# SQL vectors are always passed through as is
var_name <- SQL("select")
var_name
dbQuoteString(ANSI(), var_name)

# This mechanism is used to prevent double escaping
dbQuoteString(ANSI(), dbQuoteString(ANSI(), name))

Quote identifiers

This section describes the behavior of the following method: 

dbQuoteIdentifier(conn, x, ...)

Description

Call this method to generate a string that is suitable for use in a query as a column name, to make sure that you generate valid SQL and avoid SQL injection.

Arguments

conn

A subclass of DBIConnection, representing an active connection to an DBMS.

x

A character vector to quote as identifier.

...

Other arguments passed on to methods.

Value

dbQuoteIdentifier() returns an object that can be coerced to character, of the same length as the input. For an empty character vector this function returns a length-0 object. An error is raised if the input contains NA, but not for an empty string.

When passing the returned object again to dbQuoteIdentifier() as x argument, it is returned unchanged. Passing objects of class SQL should also return them unchanged. (For backends it may be most convenient to return SQL objects to achieve this behavior, but this is not required.)

Specification

Calling dbGetQuery() for a query of the format SELECT 1 AS ... returns a data frame with the identifier, unquoted, as column name. Quoted identifiers can be used as table and column names in SQL queries, in particular in queries like SELECT 1 AS ... and SELECT * FROM (SELECT 1) .... This is also true for column names that are empty strings or contain special characters such as a space, a dot, a comma, or quotes used to mark strings or identifiers, if the database supports this. In any case, checking the validity of the identifier should be performed only when executing a query, and not by dbQuoteIdentifier().

Examples 

# Quoting ensures that arbitrary input is safe for use in a query
name <- "Robert'); DROP TABLE Students;--"
dbQuoteIdentifier(ANSI(), name)

# SQL vectors are always passed through as is
var_name <- SQL("select")
var_name

dbQuoteIdentifier(ANSI(), var_name)

# This mechanism is used to prevent double escaping
dbQuoteIdentifier(ANSI(), dbQuoteIdentifier(ANSI(), name))

Copy data frames from database tables

This section describes the behavior of the following method: 

dbReadTable(conn, name, ...)

Description

Reads a database table to a data frame, optionally converting a column to row names and converting the column names to valid R identifiers.

Arguments

conn

A DBIConnection object, as returned by dbConnect().

name

A character string specifying the unquoted DBMS table name, or the result of a call to dbQuoteIdentifier().

...

Other parameters passed on to methods.

Additional arguments

The following arguments are not part of the dbReadTable() generic (to improve compatibility across backends) but are part of the DBI specification:

  • row.names

  • check.names

They must be provided as named arguments. See the "Value" section for details on their usage.

Specification

The name argument is processed as follows, to support databases that allow non-syntactic names for their objects:

  • If an unquoted table name as string: dbReadTable() will do the quoting, perhaps by calling dbQuoteIdentifier(conn, x = name)

  • If the result of a call to dbQuoteIdentifier(): no more quoting is done

Value

dbReadTable() returns a data frame that contains the complete data from the remote table, effectively the result of calling dbGetQuery() with SELECT * FROM <name>. An error is returned if the table does not exist. An empty table is returned as a data frame with zero rows.

The presence of rownames depends on the row.names argument, see sqlColumnToRownames() for details:

  • If FALSE, the returned data frame doesn't have row names.

  • If TRUE, a column named "row_names" is converted to row names, an error is raised if no such column exists.

  • If NA, a column named "row_names" is converted to row names if it exists, otherwise no translation occurs.

  • If a string, this specifies the name of the column in the remote table that contains the row names, an error is raised if no such column exists.

If the database supports identifiers with special characters, the columns in the returned data frame are converted to valid R identifiers if the check.names argument is TRUE, otherwise non-syntactic column names can be returned unquoted.

An error is raised if name cannot be processed with dbQuoteIdentifier() or if this results in a non-scalar. Unsupported values for row.names and check.names (non-scalars, unsupported data types, NA for check.names) also raise an error.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars[1:10, ])
dbReadTable(con, "mtcars")

dbDisconnect(con)

Copy data frames to database tables

This section describes the behavior of the following method: 

dbWriteTable(conn, name, value, ...)

Description

Writes, overwrites or appends a data frame to a database table, optionally converting row names to a column and specifying SQL data types for fields.

Arguments

conn

A DBIConnection object, as returned by dbConnect().

name

A character string specifying the unquoted DBMS table name, or the result of a call to dbQuoteIdentifier().

value

a data.frame (or coercible to data.frame).

...

Other parameters passed on to methods.

Additional arguments

The following arguments are not part of the dbWriteTable() generic (to improve compatibility across backends) but are part of the DBI specification:

  • row.names (default: NA)

  • overwrite (default: FALSE)

  • append (default: FALSE)

  • field.types (default: NULL)

  • temporary (default: FALSE)

They must be provided as named arguments. See the "Specification" and "Value" sections for details on their usage.

Specification

The name argument is processed as follows, to support databases that allow non-syntactic names for their objects:

  • If an unquoted table name as string: dbWriteTable() will do the quoting, perhaps by calling dbQuoteIdentifier(conn, x = name)

  • If the result of a call to dbQuoteIdentifier(): no more quoting is done

If the overwrite argument is TRUE, an existing table of the same name will be overwritten. This argument doesn't change behavior if the table does not exist yet.

If the append argument is TRUE, the rows in an existing table are preserved, and the new data are appended. If the table doesn't exist yet, it is created.

If the temporary argument is TRUE, the table is not available in a second connection and is gone after reconnecting. Not all backends support this argument. A regular, non-temporary table is visible in a second connection and after reconnecting to the database.

SQL keywords can be used freely in table names, column names, and data. Quotes, commas, and spaces can also be used in the data, and, if the database supports non-syntactic identifiers, also for table names and column names.

The following data types must be supported at least, and be read identically with dbReadTable():

  • integer

  • numeric (also with Inf and NaN values, the latter are translated to NA)

  • logical

  • NA as NULL

  • 64-bit values (using "bigint" as field type)

  • character (in both UTF-8 and native encodings)

  • factor (returned as character)

  • list of raw (if supported by the database)

  • date (if supported by the database; returned as Date)

  • time (if supported by the database; returned as objects that inherit from difftime)

  • timestamp (if supported by the database; returned as POSIXlt with time zone support)

The interpretation of rownames depends on the row.names argument, see sqlRownamesToColumn() for details:

  • If FALSE, row names are ignored.

  • If TRUE, row names are converted to a column named "row_names", even if the input data frame only has natural row names from 1 to nrow(...).

  • If NA, a column named "row_names" is created if the data has custom row names, no extra column is created in the case of natural row names.

  • If a string, this specifies the name of the column in the remote table that contains the row names, even if the input data frame only has natural row names.

Value

dbWriteTable() returns TRUE, invisibly. If the table exists (and both append and overwrite arguments are unset), an error is raised; the remote table remains unchanged.

An error is also raised if name cannot be processed with dbQuoteIdentifier() or if this results in a non-scalar. Invalid values for the additional arguments row.names, overwrite, append, field.types, and temporary (non-scalars, unsupported data types, NA, incompatible values) also raise an error.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars[1:5, ])
dbReadTable(con, "mtcars")

dbWriteTable(con, "mtcars", mtcars[6:10, ], append = TRUE)
dbReadTable(con, "mtcars")

dbWriteTable(con, "mtcars", mtcars[1:10, ], overwrite = TRUE)
dbReadTable(con, "mtcars")

# No row names
dbWriteTable(con, "mtcars", mtcars[1:10, ], overwrite = TRUE, row.names = FALSE)
dbReadTable(con, "mtcars")

List remote tables

This section describes the behavior of the following method: 

dbListTables(conn, ...)

Description

Returns the unquoted names of remote tables accessible through this connection. This should, where possible, include temporary tables, and views.

Arguments

conn

A DBIConnection object, as returned by dbConnect().

...

Other parameters passed on to methods.

Additional arguments

TBD: temporary = NA

This must be provided as named argument. See the "Specification" section for details on their usage.

Value

dbListTables() returns a character vector that enumerates all tables and views in the database. Tables added with dbWriteTable() are part of the list, including temporary tables if supported by the database. As soon a table is removed from the database, it is also removed from the list of database tables.

The returned names are suitable for quoting with dbQuoteIdentifier().

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbListTables(con)
dbWriteTable(con, "mtcars", mtcars)
dbListTables(con)

dbDisconnect(con)

Does a table exist?

This section describes the behavior of the following method: 

dbExistsTable(conn, name, ...)

Description

Returns if a table given by name exists in the database.

Arguments

conn

A DBIConnection object, as returned by dbConnect().

name

A character string specifying a DBMS table name.

...

Other parameters passed on to methods.

Additional arguments

TBD: temporary = NA

This must be provided as named argument. See the "Specification" section for details on their usage.

Specification

The name argument is processed as follows, to support databases that allow non-syntactic names for their objects:

  • If an unquoted table name as string: dbExistsTable() will do the quoting, perhaps by calling dbQuoteIdentifier(conn, x = name)

  • If the result of a call to dbQuoteIdentifier(): no more quoting is done

For all tables listed by dbListTables(), dbExistsTable() returns TRUE.

Value

dbExistsTable() returns a logical scalar, TRUE if the table or view specified by the name argument exists, FALSE otherwise. This includes temporary tables if supported by the database.

An error is raised if name cannot be processed with dbQuoteIdentifier() or if this results in a non-scalar.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbExistsTable(con, "iris")
dbWriteTable(con, "iris", iris)
dbExistsTable(con, "iris")

dbDisconnect(con)

Remove a table from the database

This section describes the behavior of the following method: 

dbRemoveTable(conn, name, ...)

Description

Remove a remote table (e.g., created by dbWriteTable()) from the database.

Arguments

conn

A DBIConnection object, as returned by dbConnect().

name

A character string specifying a DBMS table name.

...

Other parameters passed on to methods.

Value

dbRemoveTable() returns TRUE, invisibly. If the table does not exist, an error is raised. An attempt to remove a view with this function may result in an error.

An error is raised if name cannot be processed with dbQuoteIdentifier() or if this results in a non-scalar.

Specification

A table removed by dbRemoveTable() doesn't appear in the list of tables returned by dbListTables(), and dbExistsTable() returns FALSE. The removal propagates immediately to other connections to the same database. This function can also be used to remove a temporary table.

The name argument is processed as follows, to support databases that allow non-syntactic names for their objects:

  • If an unquoted table name as string: dbRemoveTable() will do the quoting, perhaps by calling dbQuoteIdentifier(conn, x = name)

  • If the result of a call to dbQuoteIdentifier(): no more quoting is done

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbExistsTable(con, "iris")
dbWriteTable(con, "iris", iris)
dbExistsTable(con, "iris")
dbRemoveTable(con, "iris")
dbExistsTable(con, "iris")

dbDisconnect(con)

Is this DBMS object still valid?

This section describes the behavior of the following method: 

dbIsValid(dbObj, ...)

Description

This generic tests whether a database object is still valid (i.e. it hasn't been disconnected or cleared).

Arguments

dbObj

An object inheriting from DBIObject, i.e. DBIDriver, DBIConnection, or a DBIResult

...

Other arguments to methods.

Value

dbIsValid() returns a logical scalar, TRUE if the object specified by dbObj is valid, FALSE otherwise. A DBIConnection object is initially valid, and becomes invalid after disconnecting with dbDisconnect(). A DBIResult object is valid after a call to dbSendQuery(), and stays valid even after all rows have been fetched; only clearing it with dbClearResult() invalidates it. A DBIResult object is also valid after a call to dbSendStatement(), and stays valid after querying the number of rows affected; only clearing it with dbClearResult() invalidates it. If the connection to the database system is dropped (e.g., due to connectivity problems, server failure, etc.), dbIsValid() should return FALSE. This is not tested automatically.

Examples 

dbIsValid(RSQLite::SQLite())

con <- dbConnect(RSQLite::SQLite(), ":memory:")
dbIsValid(con)

rs <- dbSendQuery(con, "SELECT 1")
dbIsValid(rs)

dbClearResult(rs)
dbIsValid(rs)

dbDisconnect(con)
dbIsValid(con)

Completion status

This section describes the behavior of the following method: 

dbHasCompleted(res, ...)

Description

This method returns if the operation has completed. A SELECT query is completed if all rows have been fetched. A data manipulation statement is always completed.

Arguments

res

An object inheriting from DBIResult.

...

Other arguments passed on to methods.

Value

dbHasCompleted() returns a logical scalar. For a query initiated by dbSendQuery() with non-empty result set, dbHasCompleted() returns FALSE initially and TRUE after calling dbFetch() without limit. For a query initiated by dbSendStatement(), dbHasCompleted() always returns TRUE. Attempting to query completion status for a result set cleared with dbClearResult() gives an error.

Specification

The completion status for a query is only guaranteed to be set to FALSE after attempting to fetch past the end of the entire result. Therefore, for a query with an empty result set, the initial return value is unspecified, but the result value is TRUE after trying to fetch only one row. Similarly, for a query with a result set of length n, the return value is unspecified after fetching n rows, but the result value is TRUE after trying to fetch only one more row.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars)
rs <- dbSendQuery(con, "SELECT * FROM mtcars")

dbHasCompleted(rs)
ret1 <- dbFetch(rs, 10)
dbHasCompleted(rs)
ret2 <- dbFetch(rs)
dbHasCompleted(rs)

dbClearResult(rs)
dbDisconnect(con)

Get the statement associated with a result set

This section describes the behavior of the following method: 

dbGetStatement(res, ...)

Description

Returns the statement that was passed to dbSendQuery() or dbSendStatement().

Arguments

res

An object inheriting from DBIResult.

...

Other arguments passed on to methods.

Value

dbGetStatement() returns a string, the query used in either dbSendQuery() or dbSendStatement(). Attempting to query the statement for a result set cleared with dbClearResult() gives an error.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars)
rs <- dbSendQuery(con, "SELECT * FROM mtcars")
dbGetStatement(rs)

dbClearResult(rs)
dbDisconnect(con)

The number of rows fetched so far

This section describes the behavior of the following method: 

dbGetRowCount(res, ...)

Description

Returns the total number of rows actually fetched with calls to dbFetch() for this result set.

Arguments

res

An object inheriting from DBIResult.

...

Other arguments passed on to methods.

Value

dbGetRowCount() returns a scalar number (integer or numeric), the number of rows fetched so far. After calling dbSendQuery(), the row count is initially zero. After a call to dbFetch() without limit, the row count matches the total number of rows returned. Fetching a limited number of rows increases the number of rows by the number of rows returned, even if fetching past the end of the result set. For queries with an empty result set, zero is returned even after fetching. For data manipulation statements issued with dbSendStatement(), zero is returned before and after calling dbFetch(). Attempting to get the row count for a result set cleared with dbClearResult() gives an error.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars)
rs <- dbSendQuery(con, "SELECT * FROM mtcars")

dbGetRowCount(rs)
ret1 <- dbFetch(rs, 10)
dbGetRowCount(rs)
ret2 <- dbFetch(rs)
dbGetRowCount(rs)
nrow(ret1) + nrow(ret2)

dbClearResult(rs)
dbDisconnect(con)

The number of rows affected

This section describes the behavior of the following method: 

dbGetRowsAffected(res, ...)

Description

This method returns the number of rows that were added, deleted, or updated by a data manipulation statement.

Arguments

res

An object inheriting from DBIResult.

...

Other arguments passed on to methods.

Value

dbGetRowsAffected() returns a scalar number (integer or numeric), the number of rows affected by a data manipulation statement issued with dbSendStatement(). The value is available directly after the call and does not change after calling dbFetch(). For queries issued with dbSendQuery(), zero is returned before and after the call to dbFetch(). Attempting to get the rows affected for a result set cleared with dbClearResult() gives an error.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "mtcars", mtcars)
rs <- dbSendStatement(con, "DELETE FROM mtcars")
dbGetRowsAffected(rs)
nrow(mtcars)

dbClearResult(rs)
dbDisconnect(con)

Begin/commit/rollback SQL transactions

This section describes the behavior of the following methods: 

dbBegin(conn, ...)

dbCommit(conn, ...)

dbRollback(conn, ...)

Description

A transaction encapsulates several SQL statements in an atomic unit. It is initiated with dbBegin() and either made persistent with dbCommit() or undone with dbRollback(). In any case, the DBMS guarantees that either all or none of the statements have a permanent effect. This helps ensuring consistency of write operations to multiple tables.

Arguments

conn

A DBIConnection object, as returned by dbConnect().

...

Other parameters passed on to methods.

Details

Not all database engines implement transaction management, in which case these methods should not be implemented for the specific DBIConnection subclass.

Value

dbBegin(), dbCommit() and dbRollback() return TRUE, invisibly. The implementations are expected to raise an error in case of failure, but this is not tested. In any way, all generics throw an error with a closed connection. In addition, a call to dbCommit() or dbRollback() without a prior call to dbBegin() raises an error. Nested transactions are not supported by DBI, an attempt to call dbBegin() twice yields an error.

Specification

Actual support for transactions may vary between backends. A transaction is initiated by a call to dbBegin() and committed by a call to dbCommit(). Data written in a transaction must persist after the transaction is committed. For example, a table that is missing when the transaction is started but is created and populated during the transaction must exist and contain the data added there both during and after the transaction, and also in a new connection.

A transaction can also be aborted with dbRollback(). All data written in such a transaction must be removed after the transaction is rolled back. For example, a table that is missing when the transaction is started but is created during the transaction must not exist anymore after the rollback.

Disconnection from a connection with an open transaction gives a warning and effectively rolls back the transaction. All data written in such a transaction must be removed after the transaction is rolled back.

The behavior is not specified if other arguments are passed to these functions. In particular, RSQLite issues named transactions with support for nesting if the name argument is set.

The transaction isolation level is not specified by DBI.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "cash", data.frame(amount = 100))
dbWriteTable(con, "account", data.frame(amount = 2000))

# All operations are carried out as logical unit:
dbBegin(con)
withdrawal <- 300
dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal))
dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal))
dbCommit(con)

dbReadTable(con, "cash")
dbReadTable(con, "account")

# Rolling back after detecting negative value on account:
dbBegin(con)
withdrawal <- 5000
dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal))
dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal))
if (dbReadTable(con, "account")$amount >= 0) {
  dbCommit(con)
} else {
  dbRollback(con)
}

dbReadTable(con, "cash")
dbReadTable(con, "account")

dbDisconnect(con)

Self-contained SQL transactions

This section describes the behavior of the following methods: 

dbWithTransaction(conn, code, ...)

dbBreak()

Description

Given that transactions are implemented, this function allows you to pass in code that is run in a transaction. The default method of dbWithTransaction() calls dbBegin() before executing the code, and dbCommit() after successful completion, or dbRollback() in case of an error. The advantage is that you don't have to remember to do dbBegin() and dbCommit() or dbRollback() – that is all taken care of. The special function dbBreak() allows an early exit with rollback, it can be called only inside dbWithTransaction().

Arguments

conn

A DBIConnection object, as returned by dbConnect().

code

An arbitrary block of R code.

...

Other parameters passed on to methods.

Details

DBI implements dbWithTransaction(), backends should need to override this generic only if they implement specialized handling.

Value

dbWithTransaction() returns the value of the executed code. Failure to initiate the transaction (e.g., if the connection is closed of if dbBegin() has been called already) gives an error.

Specification

dbWithTransaction() initiates a transaction with dbBegin(), executes the code given in the code argument, and commits the transaction with dbCommit(). If the code raises an error, the transaction is instead aborted with dbRollback(), and the error is propagated. If the code calls dbBreak(), execution of the code stops and the transaction is silently aborted. All side effects caused by the code (such as the creation of new variables) propagate to the calling environment.

Examples 

con <- dbConnect(RSQLite::SQLite(), ":memory:")

dbWriteTable(con, "cash", data.frame(amount = 100))
dbWriteTable(con, "account", data.frame(amount = 2000))

# All operations are carried out as logical unit:
dbWithTransaction(
  con,
  {
    withdrawal <- 300
    dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal))
    dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal))
  }
)

# The code is executed as if in the curent environment:
withdrawal

# The changes are committed to the database after successful execution:
dbReadTable(con, "cash")
dbReadTable(con, "account")

# Rolling back with dbBreak():
dbWithTransaction(
  con,
  {
    withdrawal <- 5000
    dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal))
    dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal))
    if (dbReadTable(con, "account")$amount < 0) {
      dbBreak()
    }
  }
)

# These changes were not committed to the database:
dbReadTable(con, "cash")
dbReadTable(con, "account")

dbDisconnect(con)
DBI/inst/doc/backend.html0000644000176200001440000005726013070016501014652 0ustar liggesusers Implementing a new backend

Implementing a new backend

Hadley Wickham

2017-04-01

The goal of this document is to help you implement a new backend for DBI.

If you are writing a package that connects a database to R, I highly recommend that you make it DBI compatible because it makes your life easier by spelling out exactly what you need to do. The consistent interface provided by DBI makes it easier for you to implement the package (because you have fewer arbitrary choices to make), and easier for your users (because it follows a familiar pattern). In addition, the DBItest package provides test cases which you can easily incorporate in your package.

I’ll illustrate the process using a fictional database called Kazam.

Getting started

Start by creating a package. It’s up to you what to call the package, but following the existing pattern of RSQLite, RMySQL, RPostgres and ROracle will make it easier for people to find it. For this example, I’ll call my package RKazam.

In your DESCRIPTION, make sure to include:

Imports:
  DBI (>= 0.3.0),
  methods
Suggests:
  DBItest, testthat

Importing DBI is fine, because your users are not supposed to attach your package anyway; the preferred method is to attach DBI and use explicit qualification via :: to access the driver in your package (which needs to be done only once).

Testing

Why testing at this early stage? Because testing should be an integral part of the software development cycle. Test right from the start, add automated tests as you go, finish faster (because tests are automated) while maintaining superb code quality (because tests also check corner cases that you might not be aware of). Don’t worry: if some test cases are difficult or impossible to satisfy, or take too long to run, you can just turn them off.

Take the time now to head over to the DBItest vignette. You will find a vast amount of ready-to-use test cases that will help you in the process of implementing your new DBI backend.

vignette("test", package = "DBItest")

Add custom tests that are not covered by DBItest at your discretion, or enhance DBItest and file a pull request if the test is generic enough to be useful for many DBI backends.

Driver

Start by making a driver class which inherits from DBIDriver. This class doesn’t need to do anything, it’s just used to dispatch other generics to the right method. Users don’t need to know about this, so you can remove it from the default help listing with @keywords internal:

#' Driver for Kazam database.
#' 
#' @keywords internal
#' @export
#' @import DBI
#' @import methods
setClass("KazamDriver", contains = "DBIDriver")

The driver class was more important in older versions of DBI, so you should also provide a dummy dbUnloadDriver() method.

#' @export
#' @rdname Kazam-class
setMethod("dbUnloadDriver", "KazamDriver", function(drv, ...) {
  TRUE
})
#> [1] "dbUnloadDriver"

If your package needs global setup or tear down, do this in the .onLoad() and .onUnload() functions.

You might also want to add a show method so the object prints nicely:

setMethod("show", "KazamDriver", function(object) {
  cat("<KazamDriver>\n")
})
#> [1] "show"

Next create Kazam() which instantiates this class.

#' @export
Kazam <- function() {
  new("KazamDriver")
}

Kazam()
#> <KazamDriver>

Connection

Next create a connection class that inherits from DBIConnection. This should store all the information needed to connect to the database. If you’re talking to a C api, this will include a slot that holds an external pointer.

#' Kazam connection class.
#' 
#' @export
#' @keywords internal
setClass("KazamConnection", 
  contains = "DBIConnection", 
  slots = list(
    host = "character", 
    username = "character", 
    # and so on
    ptr = "externalptr"
  )
)

Now you have some of the boilerplate out of the way, you can start work on the connection. The most important method here is dbConnect() which allows you to connect to a specified instance of the database. Note the use of @rdname Kazam. This ensures that Kazam() and the connect method are documented together.

#' @param drv An object created by \code{Kazam()} 
#' @rdname Kazam
#' @export
#' @examples
#' \dontrun{
#' db <- dbConnect(RKazam::Kazam())
#' dbWriteTable(db, "mtcars", mtcars)
#' dbGetQuery(db, "SELECT * FROM mtcars WHERE cyl == 4")
#' }
setMethod("dbConnect", "KazamDriver", function(drv, ...) {
  # ...
  
  new("KazamConnection", host = host, ...)
})
#> [1] "dbConnect"

Next, implement show() and dbDisconnect() methods.

Results

Finally, you’re ready to implement the meat of the system: fetching results of a query into a data frame. First define a results class:

#' Kazam results class.
#' 
#' @keywords internal
#' @export
setClass("KazamResult", 
  contains = "DBIResult",
  slots = list(ptr = "externalptr")
)

Then write a dbSendQuery() method. This takes a connection and SQL string as arguments, and returns a result object. Again ... is needed for compatibility with the generic, but you can add other arguments if you need them.

#' Send a query to Kazam.
#' 
#' @export
#' @examples 
#' # This is another good place to put examples
setMethod("dbSendQuery", "KazamConnection", function(conn, statement, ...) {
  # some code
  new("KazamResult", ...)
})
#> [1] "dbSendQuery"

Next, implement dbClearResult(), which should close the result set and free all resources associated with it:

#' @export
setMethod("dbClearResult", "KazamResult", function(res, ...) {
  # free resources
  TRUE
})
#> [1] "dbClearResult"

The hardest part of every DBI package is writing the dbFetch() method. This needs to take a result set and (optionally) number of records to return, and create a dataframe. Mapping R’s data types to those of your database may require a custom implementation of the dbDataType() method for your connection class:

#' Retrieve records from Kazam query
#' @export
setMethod("dbFetch", "KazamResult", function(res, n = -1, ...) {
  ...
})
#> [1] "dbFetch"

# (optionally)

#' Find the database data type associated with an R object
#' @export
setMethod("dbDataType", "KazamConnection", function(dbObj, obj, ...) {
  ...
})
#> [1] "dbDataType"

Next, implement dbHasCompleted() which should return a logical indicating if there are any rows remaining to be fetched.

#' @export
setMethod("dbHasCompleted", "KazamResult", function(res, ...) { 
  
})
#> [1] "dbHasCompleted"

With these four methods in place, you can now use the default dbGetQuery() to send a query to the database, retrieve results if available and then clean up. Spend some time now making sure this works with an existing database, or relax and let the DBItest package do the work for you.

SQL methods

You’re now on the home stretch, and can make your wrapper substantially more useful by implementing methods that wrap around variations in SQL across databases:

Metadata methods

There are a lot of extra metadata methods for result sets (and one for the connection) that you might want to implement. They are described in the following.

Full DBI compliance

By now, your package should implement all methods defined in the DBI specification. If you want to walk the extra mile, offer a read-only mode that allows your users to be sure that their valuable data doesn’t get destroyed inadvertently.

DBI/inst/doc/DBI-proposal.html0000644000176200001440000013325413070016501015514 0ustar liggesusers A Common Interface to Relational Databases from R and S – A Proposal

A Common Interface to Relational Databases from R and S – A Proposal

David James

March 16, 2000

For too long S and similar data analysis environments have lacked good interfaces to relational database systems (RDBMS). For the last twenty years or so these RDBMS have evolved into highly optimized client-server systems for data storage and manipulation, and currently they serve as repositories for most of the business, industrial, and research “raw” data that analysts work with. Other analysis packages, such as SAS, have traditionally provided good data connectivity, but S and GNU R have relied on intermediate text files as means of importing data (but see (R Data Import/Export 2001) and (Using Relational Database Systems with R 2000).) Although this simple approach works well for relatively modest amounts of mostly static data, it does not scale up to larger amounts of data distributed over machines and locations, nor does it scale up to data that is highly dynamic – situations that are becoming increasingly common.

We want to propose a common interface between R/S and RDBMS that would allow users to access data stored on database servers in a uniform and predictable manner irrespective of the database engine. The interface defines a small set of classes and methods similar in spirit to Python’s DB-API, Java’s JDBC, Microsoft’s ODBC, Perl’s DBI, etc., but it conforms to the “whole-object” philosophy so natural in S and R.

Computing with Distributed Data

As data analysts, we are increasingly faced with the challenge of larger data sources distributed over machines and locations; most of these data sources reside in relational database management systems (RDBMS). These relational databases represent a mature client-server distributed technology that we as analysts could be exploiting more that we’ve done in the past. The relational technology provides a well-defined standard, the ANSI SQL-92 (X/Open CAE Specification: SQL and RDA 1994), both for defining and manipulating data in a highly optimized fashion from virtually any application.

In contrast, S and Splus have provided somewhat limited tools for coping with the challenges of larger and distributed data sets (Splus does provide an import function to import from databases, but it is quite limited in terms of SQL facilities). The R community has been more resourceful and has developed a number of good libraries for connecting to mSQL, MySQL, PostgreSQL, and ODBC; each library, however, has defined its own interface to each database engine a bit differently. We think it would be to everybody’s advantage to coordinate the definition of a common interface, an effort not unlike those taken in the Python and Perl communities.

The goal of a common, seamless access to distributed data is a modest one in our evolution towards a fully distributed computing environment. We recognize the greater goal of distributed computing as the means to fully integrate diverse systems – not just databases – into a truly flexible analysis environment. Good connectivity to databases, however, is of immediate necessity both in practical terms and as a means to help us transition from monolithic, self-contained systems to those in which computations, not only the data, can be carried out in parallel over a wide number of computers and/or systems Temple Lang (2000). Issues of reliability, security, location transparency, persistence, etc., will be new to most of us and working with distributed data may provide a more gradual change to ease in the ultimate goal of full distributed computing.

A Common Interface

We believe that a common interface to databases can help users easily access data stored in RDBMS. A common interface would describe, in a uniform way, how to connect to RDBMS, extract meta-data (such as list of available databases, tables, etc.) as well as a uniform way to execute SQL statements and import their output into R and S. The current emphasis is on querying databases and not so much in a full low-level interface for database development as in JDBC or ODBC, but unlike these, we want to approach the interface from the “whole-object” perspective J. M. Chambers (1998) so natural to R/S and Python – for instance, by fetching all fields and records simultaneously into a single object.

The basic idea is to split the interface into a front-end consisting of a few classes and generic functions that users invoke and a back-end set of database-specific classes and methods that implement the actual communication. (This is a very well-known pattern in software engineering, and another good verbatim is the device-independent graphics in R/S where graphics functions produce similar output on a variety of different devices, such X displays, Postscript, etc.)

The following verbatim shows the front-end:

> mgr <- dbManager("Oracle")  
> con <- dbConnect(mgr, user = "user", passwd = "passwd")
> rs <- dbExecStatement(con, 
          "select fld1, fld2, fld3 from MY_TABLE")
> tbls <- fetch(rs, n = 100)
> hasCompleted(rs)
[1] T
> close(rs)
> rs <- dbExecStatement(con, 
          "select id_name, q25, q50 from liv2")
> res <- fetch(rs)
> getRowCount(rs)
[1] 73
> close(con)

Such scripts should work with other RDBMS (say, MySQL) by replacing the first line with

> mgr <- dbManager("MySQL")

Interface Classes

The following are the main RS-DBI classes. They need to be extended by individual database back-ends (MySQL, Oracle, etc.)

dbManager

Virtual class1 extended by actual database managers, e.g., Oracle, MySQL, Informix.

dbConnection

Virtual class that captures a connection to a database instance2.

dbResult

Virtual class that describes the result of an SQL statement.

dbResultSet

Virtual class, extends dbResult to fully describe the output of those statements that produce output records, i.e., SELECT (or SELECT-like) SQL statement.

All these classes should implement the methods show, describe, and getInfo:

show

(print in R) prints a one-line identification of the object.

describe

prints a short summary of the meta-data of the specified object (like summary in R/S).

getInfo

takes an object of one of the above classes and a string specifying a meta-data item, and it returns the corresponding information (NULL if unavailable).

> mgr <- dbManager("MySQL")
> getInfo(mgr, "version")
> con <- dbConnect(mgr, ...)
> getInfo(con, "type")

The reason we implement the meta-data through getInfo in this way is to simplify the writing of database back-ends. We don’t want to overwhelm the developers of drivers (ourselves, most likely) with hundreds of methods as in the case of JDBC.

In addition, the following methods should also be implemented:

getDatabases

lists all available databases known to the dbManager.

getTables

lists tables in a database.

getTableFields

lists the fields in a table in a database.

getTableIndices

lists the indices defined for a table in a database.

These methods may be implemented using the appropriate getInfo method above.

In the next few sections we describe in detail each of these classes and their methods.

Class dbManager

This class identifies the relational database management system. It needs to be extended by individual back-ends (Oracle, PostgreSQL, etc.) The dbManager class defines the following methods:

load

initializes the driver code. We suggest having the generator, dbManager(driver), automatically load the driver.

unload

releases whatever resources the driver is using.

getVersion

returns the version of the RS-DBI currently implemented, plus any other relevant information about the implementation itself and the RDBMS being used.

Class dbConnection

This virtual class captures a connection to a RDBMS, and it provides access to dynamic SQL, result sets, RDBMS session management (transactions), etc. Note that the dbManager may or may not allow multiple simultaneous connections. The methods it defines include:

dbConnect

opens a connection to the database dbname. Other likely arguments include host, user, and password. It returns an object that extends dbConnection in a driver-specific manner (e.g., the MySQL implementation creates a connection of class MySQLConnection that extends dbConnection). Note that we could separate the steps of connecting to a RDBMS and opening a database there (i.e., opening an instance). For simplicity we do the 2 steps in this method. If the user needs to open another instance in the same RDBMS, just open a new connection.

close

closes the connection and discards all pending work.

dbExecStatement

submits one SQL statement. It returns a dbResult object, and in the case of a SELECT statement, the object also inherits from dbResultSet. This dbResultSet object is needed for fetching the output rows of SELECT statements. The result of a non-SELECT statement (e.g., UPDATE, DELETE, CREATE, ALTER, …) is defined as the number of rows affected (this seems to be common among RDBMS).

commit

commits pending transaction (optional).

rollback

undoes current transaction (optional).

callProc

invokes a stored procedure in the RDBMS (tentative). Stored procedures are not part of the ANSI SQL-92 standard and possibly vary substantially from one RDBMS to another. For instance, Oracle seems to have a fairly decent implementation of stored procedures, but MySQL currently does not support them.

dbExec

submit an SQL “script” (multiple statements). May be implemented by looping with dbExecStatement.

dbNextResultSet

When running SQL scripts (multiple statements), it closes the current result set in the dbConnection, executes the next statement and returns its result set.

Class dbResult

This virtual class describes the result of an SQL statement (any statement) and the state of the operation. Non-query statements (e.g., CREATE, UPDATE, DELETE) set the “completed” state to 1, while SELECT statements to 0. Error conditions set this slot to a negative number. The dbResult class defines the following methods:

getStatement

returns the SQL statement associated with the result set.

getDBConnection

returns the dbConnection associated with the result set.

getRowsAffected

returns the number of rows affected by the operation.

hasCompleted

was the operation completed? SELECT’s, for instance, are not completed until their output rows are all fetched.

getException

returns the status of the last SQL statement on a given connection as a list with two members, status code and status description.

Class dbResultSet

This virtual class extends dbResult, and it describes additional information from the result of a SELECT statement and the state of the operation. The completed state is set to 0 so long as there are pending rows to fetch. The dbResultSet class defines the following additional methods:

getRowCount

returns the number of rows fetched so far.

getNullOk

returns a logical vector with as many elements as there are fields in the result set, each element describing whether the corresponding field accepts NULL values.

getFields

describes the SELECTed fields. The description includes field names, RDBMS internal data types, internal length, internal precision and scale, null flag (i.e., column allows NULL’s), and corresponding S classes (which can be over-ridden with user-provided classes). The current MySQL and Oracle implementations define a dbResultSet as a named list with the following elements:

connection:

the connection object associated with this result set;

statement:

a string with the SQL statement being processed;

description:

a field description data.frame with as many rows as there are fields in the SELECT output, and columns specifying the name, type, length, precision, scale, Sclass of the corresponding output field.

rowsAffected:

the number of rows that were affected;

rowCount:

the number of rows so far fetched;

completed:

a logical value describing whether the operation has completed or not.

nullOk:

a logical vector specifying whether the corresponding column may take NULL values.

The methods above are implemented as accessor functions to this list in the obvious way.

setDataMappings

defines a conversion between internal RDBMS data types and R/S classes. We expect the default mappings to be by far the most common ones, but users that need more control may specify a class generator for individual fields in the result set. (See Section [sec:mappings] for details.)

close

closes the result set and frees resources both in R/S and the RDBMS.

fetch

extracts the next max.rec records (-1 means all).

Data Type Mappings

The data types supported by databases are slightly different than the data types in R and S, but the mapping between them is straightforward: Any of the many fixed and varying length character types are mapped to R/S character. Fixed-precision (non-IEEE) numbers are mapped into either doubles (numeric) or long (integer). Dates are mapped to character using the appropriate TO_CHAR function in the RDBMS (which should take care of any locale information). Some RDBMS support the type CURRENCY or MONEY which should be mapped to numeric. Large objects (character, binary, file, etc.) also need to be mapped. User-defined functions may be specified to do the actual conversion as follows:

  1. run the query (either with dbExec or dbExecStatement):

    > rs <- dbExecStatement(con, "select whatever-You-need")

  2. extract the output field definitions

    > flds <- getFields(rs)

  3. replace the class generator in the, say 3rd field, by the user own generator:

    > flds[3, "Sclass"]            # default mapping
[1] "character"

    by

    > flds[3, "Sclass"] <- "myOwnGeneratorFunction"

  4. set the new data mapping prior to fetching

    > setDataMappings(resutlSet, flds)

  5. fetch the rows and store in a data.frame

    > data <- fetch(resultSet)

Open Issues

We may need to provide some additional utilities, for instance to convert dates, to escape characters such as quotes and slashes in query strings, to strip excessive blanks from some character fields, etc. We need to decide whether we provide hooks so these conversions are done at the C level, or do all the post-processing in R or S.

Another issue is what kind of data object is the output of an SQL query. Currently the MySQL and Oracle implementations return data as a data.frame; data frames have the slight inconvenience that they automatically re-label the fields according to R/S syntax, changing the actual RDBMS labels of the variables; the issue of non-numeric data being coerced into factors automatically “at the drop of a hat” (as someone in s-news wrote) is also annoying.

The execution of SQL scripts is not fully described. The method that executes scripts could run individual statements without returning until it encounters a query (SELECT-like) statement. At that point it could return that one result set. The application is then responsible for fetching these rows, and then for invoking dbNextResultSet on the opened dbConnection object to repeat the dbExec/fetch loop until it encounters the next dbResultSet. And so on. Another (potentially very expensive) alternative would be to run all statements sequentially and return a list of data.frames, each element of the list storing the result of each statement.

Binary objects and large objects present some challenges both to R and S. It is becoming more common to store images, sounds, and other data types as binary objects in RDBMS, some of which can be in principle quite large. The SQL-92 ANSI standard allows up to 2 gigabytes for some of these objects. We need to carefully plan how to deal with binary objects – perhaps tentatively not in full generality. Large objects could be fetched by repeatedly invoking a specified R/S function that takes as argument chunks of a specified number of raw bytes. In the case of S4 (and Splus5.x) the RS-DBI implementation can write into an opened connection for which the user has defined a reader (but can we guarantee that we won’t overflow the connection?). In the case of R it is not clear what data type binary large objects (BLOB) should be mapped into.

Limitations

These are some of the limitations of the current interface definition:

  • we only allow one SQL statement at a time, forcing users to split SQL scripts into individual statements;

  • transaction management is not fully described;

  • the interface is heavily biased towards queries, as opposed to general purpose database development. In particular we made no attempt to define “bind variables”; this is a mechanism by which the contents of S objects are implicitly moved to the database during SQL execution. For instance, the following embedded SQL statement

      /* SQL */
  SELECT * from emp_table where emp_id = :sampleEmployee

    would take the vector sampleEmployee and iterate over each of its elements to get the result. Perhaps RS-DBI could at some point in the future implement this feature.

Other Approaches

The high-level, front-end description of RS-DBI is the more critical aspect of the interface. Details on how to actually implement this interface may change over time. The approach described in this document based on one back-end driver per RDBMS is reasonable, but not the only approach – we simply felt that a simpler approach based on well-understood and self-contained tools (R, S, and C API’s) would be a better start. Nevertheless we want to briefly mention a few alternatives that we considered and tentatively decided against, but may quite possibly re-visit in the near future.

Open Database Connectivity (ODBC)

The ODBC protocol was developed by Microsoft to allow connectivity among C/C++ applications and RDBMS. As you would expect, originally implementations of the ODBC were only available under Windows environments. There are various effort to create a Unix implementation (see the Unix ODBC web-site and Harvey (1999)). This approach looks promising because it allows us to write only one back-end, instead of one per RDBMS. Since most RDBMS already provide ODBC drivers, this could greatly simplify development. Unfortunately, the Unix implementation of ODBC was not mature enough at the time we looked at it, a situation we expect will change in the next year or so. At that point we will need to re-evaluate it to make sure that such an ODBC interface does not penalize the interface in terms of performance, ease of use, portability among the various Unix versions, etc.

Java Database Connectivity (JDBC)

Another protocol, the Java database connectivity, is very well-done and supported by just about every RDBMS. The issue with JDBC is that as of today neither S nor R (which are written in C) interfaces cleanly with Java. There are several efforts (some in a quite fairly advanced state) to allow S and R to invoke Java methods. Once this interface is widely available in Splus5x and R we will need to re-visit this issue again and study the performance, usability, etc., of JDBC as a common back-end to the RS-DBI.

CORBA and a 3-tier Architecture

Yet another approach is to move the interface to RDBMS out of R and S altogether into a separate system or server that would serve as a proxy between R/S and databases. The communication to this middle-layer proxy could be done through CORBA (John M. Chambers et al. 1998, Siegel (1996)), Java’s RMI, or some other similar technology. Such a design could be very flexible, but the CORBA facilities both in R and S are not widely available yet, and we do not know whether this will be made available to Splus5 users from MathSoft. Also, my experience with this technology is rather limited.

On the other hand, this 3-tier architecture seem to offer the most flexibility to cope with very large distributed databases, not necessarily relational.

Resources

The latest documentation and software on the RS-DBI was available at www.omegahat.net (link dead now: http://www.omegahat.net/contrib/RS-DBI/index.html). The R community has developed interfaces to some databases: RmSQL is an interface to the mSQL database written by Torsten Hothorn; RPgSQL is an interface to PostgreSQL and was written by Timothy H. Keitt; RODBC is an interface to ODBC, and it was written by Michael Lapsley. (For more details on all these see (R Data Import/Export 2001).)

The are R and S-Plus interfaces to MySQL that follow the propose RS-DBI API described here; also, there’s an S-Plus interface SOracle James (In preparation) to Oracle (we expect to have an R implementation soon.)

The idea of a common interface to databases has been successfully implemented in Java’s Database Connectivity (JDBC) (www.javasoft.com), in C through the Open Database Connectivity (ODBC) (www.unixodbc.org), in Python’s Database Application Programming Interface (www.python.org), and in Perl’s Database Interface (www.cpan.org).

Acknowledgements

The R/S database interface came about from suggestions, comments, and discussions with John M. Chambers and Duncan Temple Lang in the context of the Omega Project for Statistical Computing. Doug Bates and Saikat DebRoy ported (and greatly improved) the first MySQL implementation to R.

The S Version 4 Definitions

The following code is meant to serve as a detailed description of the R/S to database interface. We decided to use S4 (instead of R or S version 3) because its clean syntax help us to describe easily the classes and methods that form the RS-DBI, and also to convey the inter-class relationships.

## Define all the classes and methods to be used by an
## implementation of the RS-DataBase Interface.  Mostly, 
## these classes are virtual and each driver should extend
## them to provide the actual implementation.

## Class: dbManager 
## This class identifies the DataBase Management System
## (Oracle, MySQL, Informix, PostgreSQL, etc.)

setClass("dbManager", VIRTUAL)

setGeneric("load", 
   def = function(dbMgr,...) 
   standardGeneric("load")
   )
setGeneric("unload", 
   def = function(dbMgr,...)
   standardGeneric("unload")
   )
setGeneric("getVersion", 
   def = function(dbMgr,...) 
   standardGeneric("getVersion")
   )

## Class: dbConnections 
## This class captures a connection to a database instance. 

setClass("dbConnection", VIRTUAL)

setGeneric("dbConnection", 
   def = function(dbMgr, ...) 
   standardGeneric("dbConnection")
   )
setGeneric("dbConnect", 
   def = function(dbMgr, ...) 
   standardGeneric("dbConnect")
   )
setGeneric("dbExecStatement", 
   def = function(con, statement, ...)
   standardGeneric("dbExecStatement")
   )
setGeneric("dbExec", 
   def = function(con, statement, ...) 
   standardGeneric("dbExec")
   )
setGeneric("getResultSet", 
   def = function(con, ..) 
   standardGeneric("getResultSet")
   )
setGeneric("commit", 
   def = function(con, ...) 
   standardGeneric("commit")
   )
setGeneric("rollback", 
   def = function(con, ...) 
   standardGeneric("rollback")
   )
setGeneric("callProc", 
   def = function(con, ...) 
   standardGeneric("callProc")
   )
setMethod("close", 
   signature = list(con="dbConnection", type="missing"),
   def = function(con, type) NULL
   )

## Class: dbResult
## This is a base class for arbitrary results from the RDBMS 
## (INSERT, UPDATE, DELETE).  SELECTs (and SELECT-like) 
## statements produce "dbResultSet" objects, which extend 
## dbResult.

setClass("dbResult", VIRTUAL)

setMethod("close", 
   signature = list(con="dbResult", type="missing"),
   def = function(con, type) NULL
   )

## Class: dbResultSet
## Note that we define a resultSet as the result of a 
## SELECT  SQL statement.

setClass("dbResultSet", "dbResult")

setGeneric("fetch", 
   def = function(resultSet,n,...) 
   standardGeneric("fetch")
   )
setGeneric("hasCompleted",
   def = function(object, ...) 
   standardGeneric("hasCompleted")
   )
setGeneric("getException",
   def = function(object, ...) 
   standardGeneric("getException")
   )
setGeneric("getDBconnection",
   def = function(object, ...) 
   standardGeneric("getDBconnection")
   )
setGeneric("setDataMappings", 
   def = function(resultSet, ...) 
   standardGeneric("setDataMappings")
   )
setGeneric("getFields",
   def = function(object, table, dbname,  ...) 
   standardGeneric("getFields")
   )
setGeneric("getStatement", 
   def = function(object, ...) 
   standardGeneric("getStatement")
   )
setGeneric("getRowsAffected",
   def = function(object, ...) 
   standardGeneric("getRowsAffected")
   )
setGeneric("getRowCount",
   def = function(object, ...) 
   standardGeneric("getRowCount")
   )
setGeneric("getNullOk",
   def = function(object, ...) 
   standardGeneric("getNullOk")
   )

## Meta-data: 
setGeneric("getInfo", 
   def = function(object, ...) 
   standardGeneric("getInfo")
   )
setGeneric("describe", 
   def = function(object, verbose=F, ...)
   standardGeneric("describe")
   )
setGeneric("getCurrentDatabase",
   def = function(object, ...)
   standardGeneric("getCurrentDatabase")
   )
setGeneric("getDatabases", 
   def = function(object, ...)
   standardGeneric("getDatabases")
   )
setGeneric("getTables", 
   def = function(object, dbname, ...)
   standardGeneric("getTables")
   )
setGeneric("getTableFields", 
   def = function(object, table, dbname, ...)
   standardGeneric("getTableFields")
   )
setGeneric("getTableIndices", 
   def = function(object, table, dbname, ...) 
   standardGeneric("getTableIndices")
   )

Chambers, J. M. 1998. Programming with Data: A Guide to the S Language. New York: Springer.

Chambers, John M., Mark H. Hansen, David A. James, and Duncan Temple Lang. 1998. “Distributed Computing with Data: A Corba-Based Approach.” In Computing Science and Statistics. Inteface Foundation of North America.

Harvey, Peter. 1999. “Open Database Connectivity.” Linux Journal Nov. (67): 68–72.

James, David A. In preparation. “An R/S Interface to the Oracle Database.” www.omegahat.org: Bell Labs, Lucent Technologies.

R Data Import/Export. 2001. R-Development Core Team.

Siegel, Jon. 1996. CORBA Fundamentals and Programming. New York: Wiley.

Temple Lang, Duncan. 2000. “The Omegahat Environment: New Possibilities for Statistical Computing.” Journal of Computational and Graphical Statistics to appear.

Using Relational Database Systems with R. 2000. R-Developemt Core Team.

X/Open CAE Specification: SQL and RDA. 1994. Reading, UK: X/Open Company Ltd.

  1. A virtual class allows us to group classes that share some common functionality, e.g., the virtual class “dbConnection” groups all the connection implementations by Informix, Ingres, DB/2, Oracle, etc. Although the details will vary from one RDBMS to another, the defining characteristic of these objects is what a virtual class captures. R and S version 3 do not explicitly define virtual classes, but they can easily implement the idea through inheritance.↩

  2. The term “database” is sometimes (confusingly) used both to denote the RDBMS, such as Oracle, MySQL, and also to denote a particular database instance under a RDBMS, such as “opto” or “sales” databases under the same RDBMS.↩

DBI/inst/doc/DBI-1.Rmd0000644000176200001440000005740013070016501013571 0ustar liggesusers--- title: "A Common Database Interface (DBI)" author: "R-Databases Special Interest Group" date: "16 June 2003" output: rmarkdown::html_vignette bibliography: biblio.bib vignette: > %\VignetteIndexEntry{A Common Database Interface (DBI)} %\VignetteEngine{knitr::rmarkdown} --- This document describes a common interface between the S language (in its R and S-Plus implementations) and database management systems (DBMS). The interface defines a small set of classes and methods similar in spirit to Perl’s DBI, Java’s JDBC, Python’s DB-API, and Microsoft’s ODBC. # Version {#sec:version} This document describes version 0.1-6 of the database interface API (application programming interface). # Introduction {#sec:intro} The database interface (DBI) separates the connectivity to the DBMS into a “front-end” and a “back-end”. Applications use only the exposed “front-end” API. The facilities that communicate with specific DBMS (Oracle, PostgreSQL, etc.) are provided by “device drivers” that get invoked automatically by the S language evaluator. The following example illustrates some of the DBI capabilities: ```R ## Choose the proper DBMS driver and connect to the server drv <- dbDriver("ODBC") con <- dbConnect(drv, "dsn", "usr", "pwd") ## The interface can work at a higher level importing tables ## as data.frames and exporting data.frames as DBMS tables. dbListTables(con) dbListFields(con, "quakes") if(dbExistsTable(con, "new_results")) dbRemoveTable(con, "new_results") dbWriteTable(con, "new_results", new.output) ## The interface allows lower-level interface to the DBMS res <- dbSendQuery(con, paste( "SELECT g.id, g.mirror, g.diam, e.voltage", "FROM geom_table as g, elec_measures as e", "WHERE g.id = e.id and g.mirrortype = 'inside'", "ORDER BY g.diam")) out <- NULL while(!dbHasCompleted(res)){ chunk <- fetch(res, n = 10000) out <- c(out, doit(chunk)) } ## Free up resources dbClearResult(res) dbDisconnect(con) dbUnloadDriver(drv) ``` (only the first 2 expressions are DBMS-specific – all others are independent of the database engine itself). Individual DBI drivers need not implement all the features we list below (we indicate those that are optional). Furthermore, drivers may extend the core DBI facilities, but we suggest to have these extensions clearly indicated and documented. The following are the elements of the DBI: 1. A set of classes and methods (Section [sec:DBIClasses]) that defines what operations are possible and how they are defined, e.g.: - connect/disconnect to the DBMS - create and execute statements in the DBMS - extract results/output from statements - error/exception handling - information (meta-data) from database objects - transaction management (optional) Some things are left explicitly unspecified, e.g., authentication and even the query language, although it is hard to avoid references to SQL and relational database management systems (RDBMS). 2. Drivers Drivers are collection of functions that implement the functionality defined above in the context of specific DBMS, e.g., mSQL, Informix. 3. Data type mappings (Section [sec:data-mappings].) Mappings and conversions between DBMS data types and R/S objects. All drivers should implement the “basic” primitives (see below), but may chose to add user-defined conversion function to handle more generic objects (e.g., factors, ordered factors, time series, arrays, images). 4. Utilities (Section [sec:utilities].) These facilities help with details such as mapping of identifiers between S and DBMS (e.g., `_` is illegal in R/S names, and `.` is used for constructing compound SQL identifiers), etc. # DBI Classes and Methods {#sec:DBIClasses} The following are the main DBI classes. They need to be extended by individual database back-ends (Sybase, Oracle, etc.) Individual drivers need to provide methods for the generic functions listed here (those methods that are optional are so indicated). *Note: Although R releases prior to 1.4 do not have a formal concept of classes, we will use the syntax of the S Version 4 classes and methods (available in R releases 1.4 and later as library `methods`) to convey precisely the DBI class hierarchy, its methods, and intended behavior.* The DBI classes are `DBIObject`, `DBIDriver`, `DBIConnection` and `DBIResult`. All these are *virtual* classes. Drivers define new classes that extend these, e.g., `PgSQLDriver`, `PgSQLConnection`, and so on. ![Class hierarchy for the DBI. The top two layers are comprised of virtual classes and each lower layer represents a set of driver-specific implementation classes that provide the functionality defined by the virtual classes above.](hierarchy.png) `DBIObject`: : Virtual class[^1] that groups all other DBI classes. `DBIDriver`: : Virtual class that groups all DBMS drivers. Each DBMS driver extends this class. Typically generator functions instantiate the actual driver objects, e.g., `PgSQL`, `HDF5`, `BerkeleyDB`. `DBIConnection`: : Virtual class that encapsulates connections to DBMS. `DBIResult`: : Virtual class that describes the result of a DBMS query or statement. [Q: Should we distinguish between a simple result of DBMS statements e.g., as `delete` from DBMS queries (i.e., those that generate data).] The methods `format`, `print`, `show`, `dbGetInfo`, and `summary` are defined (and *implemented* in the `DBI` package) for the `DBIObject` base class, thus available to all implementations; individual drivers, however, are free to override them as they see fit. `format(x, ...)`: : produces a concise character representation (label) for the `DBIObject` `x`. `print(x, ...)`/`show(x)`: : prints a one-line identification of the object `x`. `summary(object, ...)`: : produces a concise description of the object. The default method for `DBIObject` simply invokes `dbGetInfo(dbObj)` and prints the name-value pairs one per line. Individual implementations may tailor this appropriately. `dbGetInfo(dbObj, ...)`: : extracts information (meta-data) relevant for the `DBIObject` `dbObj`. It may return a list of key/value pairs, individual meta-data if supplied in the call, or `NULL` if the requested meta-data is not available. *Hint:* Driver implementations may choose to allow an argument `what` to specify individual meta-data, e.g., `dbGetInfo(drv, what = max.connections)`. In the next few sub-sections we describe in detail each of these classes and their methods. ## Class `DBIObject` {#sec:DBIObject} This class simply groups all DBI classes, and thus all extend it. ## Class `DBIDriver` {#sec:DBIDriver} This class identifies the database management system. It needs to be extended by individual back-ends (Oracle, PostgreSQL, etc.) The DBI provides the generator `dbDriver(driverName)` which simply invokes the function `driverName`, which in turn instantiates the corresponding driver object. The `DBIDriver` class defines the following methods: `driverName`: : [meth:driverName] initializes the driver code. The name `driverName` refers to the actual generator function for the DBMS, e.g., `RPgSQL`, `RODBC`, `HDF5`. The driver instance object is used with `dbConnect` (see page ) for opening one or possibly more connections to one or more DBMS. `dbListConnections(drv, ...)`: : list of current connections being handled by the `drv` driver. May be `NULL` if there are no open connections. Drivers that do not support multiple connections may return the one open connection. `dbGetInfo(dbObj, ...)`: : returns a list of name-value pairs of information about the driver. *Hint:* Useful entries could include `name`: : the driver name (e.g., `RODBC`, `RPgSQL`); `driver.version`: : version of the driver; `DBI.version`: : the version of the DBI that the driver implements, e.g., `0.1-2`; `client.version`: : of the client DBMS libraries (e.g., version of the `libpq` library in the case of `RPgSQL`); `max.connections`: : maximum number of simultaneous connections; plus any other relevant information about the implementation, for instance, how the driver handles upper/lower case in identifiers. `dbUnloadDriver(driverName)` (optional): : frees all resources (local and remote) used by the driver. Returns a logical to indicate if it succeeded or not. ## Class `DBIConnection` {#sec:DBIConnection} This virtual class encapsulates the connection to a DBMS, and it provides access to dynamic queries, result sets, DBMS session management (transactions), etc. *Note:* Individual drivers are free to implement single or multiple simultaneous connections. The methods defined by the `DBIConnection` class include: `dbConnect(drv, ...)`: : [meth:dbConnect] creates and opens a connection to the database implemented by the driver `drv` (see Section [sec:DBIDriver]). Each driver will define what other arguments are required, e.g., `dbname` or `dsn` for the database name, `user`, and `password`. It returns an object that extends `DBIConnection` in a driver-specific manner (e.g., the MySQL implementation could create an object of class `MySQLConnection` that extends `DBIConnection`). `dbDisconnect(conn, ...)`: : closes the connection, discards all pending work, and frees resources (e.g., memory, sockets). Returns a logical indicating whether it succeeded or not. `dbSendQuery(conn, statement, ...)`: : submits one statement to the DBMS. It returns a `DBIResult` object. This object is needed for fetching data in case the statement generates output (see `fetch` on page ), and it may be used for querying the state of the operation; see `dbGetInfo` and other meta-data methods on page . `dbGetQuery(conn, statement, ...)`: : submit, execute, and extract output in one operation. The resulting object may be a `data.frame` if the `statement` generates output. Otherwise the return value should be a logical indicating whether the query succeeded or not. `dbGetException(conn, ...)`: : returns a list with elements `errNum` and `errMsg` with the status of the last DBMS statement sent on a given connection (this information may also be provided by the `dbGetInfo` meta-data function on the `conn` object. *Hint:* The ANSI SQL-92 defines both a status code and an status message that could be return as members of the list. `dbGetInfo(dbObj, ...)`: : returns a list of name-value pairs describing the state of the connection; it may return one or more meta-data, the actual driver method allows to specify individual pieces of meta-data (e.g., maximum number of open results/cursors). *Hint:* Useful entries could include `dbname`: : the name of the database in use; `db.version`: : the DBMS server version (e.g., “Oracle 8.1.7 on Solaris”; `host`: : host where the database server resides; `user`: : user name; `password`: : password (is this safe?); plus any other arguments related to the connection (e.g., thread id, socket or TCP connection type). `dbListResults(conn, ...)`: : list of `DBIResult` objects currently active on the connection `conn`. May be `NULL` if no result set is active on `conn`. Drivers that implement only one result set per connection could return that one object (no need to wrap it in a list). *Note: The following are convenience methods that simplify the import/export of (mainly) data.frames. The first five methods implement the core methods needed to `attach` remote DBMS to the S search path. (For details, see @data-management:1991 [@database-classes:1999].)* *Hint:* For relational DBMS these methods may be easily implemented using the core DBI methods `dbConnect`, `dbSendQuery`, and `fetch`, due to SQL reflectance (i.e., one easily gets this meta-data by querying the appropriate tables on the RDBMS). `dbListTables(conn, ...)`: : returns a character vector (possibly of zero-length) of object (table) names available on the `conn` connection. `dbReadTable(conn, name, ...)`: : imports the data stored remotely in the table `name` on connection `conn`. Use the field `row.names` as the `row.names` attribute of the output data.frame. Returns a `data.frame`. [Q: should we spell out how row.names should be created? E.g., use a field (with unique values) as row.names? Also, should `dbReadTable` reproduce a data.frame exported with `dbWriteTable`?] `dbWriteTable(conn, name, value, ...)`: : write the object `value` (perhaps after coercing it to data.frame) into the remote object `name` in connection `conn`. Returns a logical indicating whether the operation succeeded or not. `dbExistsTable(conn, name, ...)`: : does remote object `name` exist on `conn`? Returns a logical. `dbRemoveTable(conn, name, ...)`: : removes remote object `name` on connection `conn`. Returns a logical indicating whether the operation succeeded or not. `dbListFields(conn, name, ...)`: : returns a character vector listing the field names of the remote table `name` on connection `conn` (see `dbColumnInfo()` for extracting data type on a table). *Note: The following methods deal with transactions and stored procedures. All these functions are optional.* `dbCommit(conn, ...)`(optional): : commits pending transaction on the connection and returns `TRUE` or `FALSE` depending on whether the operation succeeded or not. `dbRollback(conn, ...)`(optional): : undoes current transaction on the connection and returns `TRUE` or `FALSE` depending on whether the operation succeeded or not. `dbCallProc(conn, storedProc, ...)`(optional): : invokes a stored procedure in the DBMS and returns a `DBIResult` object. [Stored procedures are *not* part of the ANSI SQL-92 standard and vary substantially from one RDBMS to another.] ## Class `DBIResult` {#sec:DBIResult} This virtual class describes the result and state of execution of a DBMS statement (any statement, query or non-query). The result set `res` keeps track of whether the statement produces output for R/S, how many rows were affected by the operation, how many rows have been fetched (if statement is a query), whether there are more rows to fetch, etc. *Note: Individual drivers are free to allow single or multiple active results per connection.* [Q: Should we distinguish between results that return no data from those that return data?] The class `DBIResult` defines the following methods: `fetch(res, n, ...)`: : [meth:fetch] fetches the next `n` elements (rows) from the result set `res` and return them as a data.frame. A value of `n=-1` is interpreted as “return all elements/rows”. `dbClearResult(res, ...)`: : flushes any pending data and frees all resources (local and remote) used by the object `res` on both sides of the connection. Returns a logical indicating success or not. `dbGetInfo(dbObj, ...)`: : returns a name-value list with the state of the result set. *Hint:* Useful entries could include `statement`: : a character string representation of the statement being executed; `rows.affected`: : number of affected records (changed, deleted, inserted, or extracted); `row.count`: : number of rows fetched so far; `has.completed`: : has the statement (query) finished? `is.select`: : a logical describing whether or not the statement generates output; plus any other relevant driver-specific meta-data. `dbColumnInfo(res, ...)`: : produces a data.frame that describes the output of a query. The data.frame should have as many rows as there are output fields in the result set, and each column in the data.frame should describe an aspect of the result set field (field name, type, etc.) *Hint:* The data.frame columns could include `field.name`: : DBMS field label; `field.type`: : DBMS field type (implementation-specific); `data.type`: : corresponding R/S data type, e.g., `integer`; `precision`/`scale`: : (as in ODBC terminology), display width and number of decimal digits, respectively; `nullable`: : whether the corresponding field may contain (DBMS) `NULL` values; plus other driver-specific information. `dbSetDataMappings(flds, ...)`(optional): : defines a conversion between internal DBMS data types and R/S classes. We expect the default mappings (see Section [sec:data-mappings]) to be by far the most common ones, but users that need more control may specify a class generator for individual fields in the result set. [This topic needs further discussion.] *Note: The following are convenience methods that extract information from the result object (they may be implemented by invoking `dbGetInfo` with appropriate arguments).* `dbGetStatement(res, ...)`(optional): : returns the DBMS statement (as a character string) associated with the result `res`. `dbGetRowsAffected(res, ...)`(optional): : returns the number of rows affected by the executed statement (number of records deleted, modified, extracted, etc.) `dbHasCompleted(res, ...)`(optional): : returns a logical that indicates whether the operation has been completed (e.g., are there more records to be fetched?). `dbGetRowCount(res, ...)`(optional): : returns the number of rows fetched so far. # Data Type Mappings {#sec:data-mappings} The data types supported by databases are different than the data types in R and S, but the mapping between the “primitive” types is straightforward: Any of the many fixed and varying length character types are mapped to R/S `character`. Fixed-precision (non-IEEE) numbers are mapped into either doubles (`numeric`) or long (`integer`). Notice that many DBMS do not follow the so-called IEEE arithmetic, so there are potential problems with under/overflows and loss of precision, but given the R/S primitive types we cannot do too much but identify these situations and warn the application (how?). By default dates and date-time objects are mapped to character using the appropriate `TO_CHAR` function in the DBMS (which should take care of any locale information). Some RDBMS support the type `CURRENCY` or `MONEY` which should be mapped to `numeric` (again with potential round off errors). Large objects (character, binary, file, etc.) also need to be mapped. User-defined functions may be specified to do the actual conversion (as has been done in other inter-systems packages [^2]). Specifying user-defined conversion functions still needs to be defined. # Utilities {#sec:utilities} The core DBI implementation should make available to all drivers some common basic utilities. For instance: `dbGetDBIVersion`: : returns the version of the currently attached DBI as a string. `dbDataType(dbObj, obj, ...)`: : returns a string with the (approximately) appropriate data type for the R/S object `obj`. The DBI can implement this following the ANSI-92 standard, but individual drivers may want/need to extend it to make use of DBMS-specific types. `make.db.names(dbObj, snames, ...)`: : maps R/S names (identifiers) to SQL identifiers replacing illegal characters (as `.`) by the legal SQL `_`. `SQLKeywords(dbObj, ...)`: : returns a character vector of SQL keywords (reserved words). The default method returns the list of `.SQL92Keywords`, but drivers should update this vector with the DBMS-specific additional reserved words. `isSQLKeyword(dbObj, name, ...)`: : for each element in the character vector `name` determine whether or not it is an SQL keyword, as reported by the generic function `SQLKeywords`. Returns a logical vector parallel to the input object `name`. # Open Issues and Limitations {#sec:open-issues} There are a number of issues and limitations that the current DBI conscientiously does not address on the interest of simplicity. We do list here the most important ones. Non-SQL: : Is it realistic to attempt to encompass non-relational databases, like HDF5, Berkeley DB, etc.? Security: : allowing users to specify their passwords on R/S scripts may be unacceptable for some applications. We need to consider alternatives where users could store authentication on files (perhaps similar to ODBC’s `odbc.ini`) with more stringent permissions. Exceptions: : the exception mechanism is a bit too simple, and it does not provide for information when problems stem from the DBMS interface itself. For instance, under/overflow or loss of precision as we move numeric data from DBMS to the more limited primitives in R/S. Asynchronous communication: : most DBMS support both synchronous and asynchronous communications, allowing applications to submit a query and proceed while the database server process the query. The application is then notified (or it may need to poll the server) when the query has completed. For large computations, this could be very useful, but the DBI would need to specify how to interrupt the server (if necessary) plus other details. Also, some DBMS require applications to use threads to implement asynchronous communication, something that neither R nor S-Plus currently addresses. SQL scripts: : the DBI only defines how to execute one SQL statement at a time, forcing users to split SQL scripts into individual statements. We need a mechanism by which users can submit SQL scripts that could possibly generate multiple result sets; in this case we may need to introduce new methods to loop over multiple results (similar to Python’s `nextResultSet`). BLOBS/CLOBS: : large objects (both character and binary) present some challenges both to R and S-Plus. It is becoming more common to store images, sounds, and other data types as binary objects in DBMS, some of which can be in principle quite large. The SQL-92 ANSI standard allows up to 2 gigabytes for some of these objects. We need to carefully plan how to deal with binary objects. Transactions: : transaction management is not fully described. Additional methods: : Do we need any additional methods? (e.g., `dbListDatabases(conn)`, `dbListTableIndices(conn, name)`, how do we list all available drivers?) Bind variables: : the interface is heavily biased towards queries, as opposed to general purpose database development. In particular we made no attempt to define “bind variables”; this is a mechanism by which the contents of R/S objects are implicitly moved to the database during SQL execution. For instance, the following embedded SQL statement /* SQL */ SELECT * from emp_table where emp_id = :sampleEmployee would take the vector `sampleEmployee` and iterate over each of its elements to get the result. Perhaps the DBI could at some point in the future implement this feature. # Resources {#sec:resources} The idea of a common interface to databases has been successfully implemented in various environments, for instance: Java’s Database Connectivity (JDBC) ([www.javasoft.com](http://www.javasoft.com/products/jdbc/index.html)). In C through the Open Database Connectivity (ODBC) ([www.unixodbc.org](http://www.unixodbc.org/)). Python’s Database Application Programming Interface ([www.python.org](http://www.python.org/topics/database)). Perl’s Database Interface ([dbi.perl.org](http://dbi.perl.org)). [^1]: A virtual class allows us to group classes that share some common characteristics, even if their implementations are radically different. [^2]: Duncan Temple Lang has volunteered to port the data conversion code found in R-Java, R-Perl, and R-Python packages to the DBI DBI/inst/doc/spec.Rmd0000644000176200001440000001115613070016501013765 0ustar liggesusers--- title: "DBI specification" author: "Kirill Müller" date: "`r Sys.Date()`" output: rmarkdown::html_document: smart: FALSE toc: TRUE toc_float: TRUE abstract: > The DBI package defines the generic DataBase Interface for R. The connection to individual DBMS is provided by other packages that import DBI (so-called *DBI backends*). This document formalizes the behavior expected by the methods declared in DBI and implemented by the individual backends. To ensure maximum portability and exchangeability, and to reduce the effort for implementing a new DBI backend, the DBItest package defines a comprehensive set of test cases that test conformance to the DBI specification. This document is derived from comments in the test definitions of the DBItest package. Any extensions or updates to the tests will be reflected in this document. vignette: > %\VignetteIndexEntry{DBI specification} %\VignetteEngine{knitr::rmarkdown} %\VignetteEncoding{UTF-8} --- ```{r echo = FALSE} library(magrittr) library(xml2) knitr::opts_chunk$set(echo = FALSE) r <- rprojroot::is_r_package$make_fix_file() ``` ```{r error=TRUE} rd_db <- tools::Rd_db(dir = r()) Links <- tools::findHTMLlinks() html_topic <- function(name) { rd <- rd_db[[paste0(name, ".Rd")]] conn <- textConnection(NULL, "w") on.exit(close(conn)) #tools::Rd2HTML(rd, conn, Links = Links) tools::Rd2HTML(rd, conn) textConnectionValue(conn) } xml_topic <- function(name, patcher) { html <- html_topic(name) x <- read_html(paste(html, collapse = "\n")) # No idea why this is necessary when embedding HTML in Markdown codes <- x %>% xml_find_all("//code[contains(., '$')]") xml_text(codes) <- gsub("[$]", "\\\\$", xml_text(codes)) xx <- x %>% xml_find_first("/html/body") xx %>% xml_find_first("//table") %>% xml_remove() patcher(xx) } asis_topic <- function(name, patcher = identity) { xml <- lapply(name, xml_topic, patcher = patcher) asis <- sapply(xml, as.character) %>% paste(collapse = "\n") knitr::asis_output(asis) } patch_package_doc <- function(x) { x %>% xml_find_first("//h3") %>% xml_remove remove_see_also_section(x) remove_authors_section(x) x } move_contents_of_usage_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 usage_contents <- x %>% xml_find_all( "//h3[.='Usage']/following-sibling::node() [not(self::h3)] [count(preceding-sibling::h3)=2]") usage_text <- usage_contents %>% xml_find_first("//pre") %>% xml_text h3 <- x %>% xml_find_first("//h3") intro_text <- read_xml( paste0( "

This section describes the behavior of the following method", if (length(grep("[(]", strsplit(usage_text, "\n")[[1]])) > 1) "s" else "", ":

") ) xml_add_sibling( h3, intro_text, .where = "before") lapply(usage_contents, xml_add_sibling, .x = h3, .copy = FALSE, .where = "before") x %>% xml_find_first("//h3[.='Usage']") %>% xml_remove x } move_additional_arguments_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error additional_arguments <- x %>% xml_find_all( "//h3[.='Additional arguments'] | //h3[.='Additional arguments']/following-sibling::node()[following-sibling::h3]") after_arg <- x %>% xml_find_first("//h3[text()='Arguments']/following-sibling::h3") lapply(additional_arguments, xml_add_sibling, .x = after_arg, .copy = FALSE, .where = "before") x } remove_see_also_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error x %>% xml_find_all( "//h3[.='See Also'] | //h3[.='See Also']/following-sibling::node()[following-sibling::h3]") %>% xml_remove() x } remove_authors_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error x %>% xml_find_all( "//h3[.='Author(s)'] | //h3[.='Author(s)']/following-sibling::node()[following-sibling::h3]") %>% xml_remove() x } patch_method_doc <- function(x) { move_contents_of_usage_section(x) remove_see_also_section(x) move_additional_arguments_section(x) x } asis_topic("DBI-package", patch_package_doc) topics <- c( "dbDataType", "dbConnect", "dbDisconnect", "dbSendQuery", "dbFetch", "dbClearResult", "dbBind", "dbGetQuery", "dbSendStatement", "dbExecute", "dbQuoteString", "dbQuoteIdentifier", "dbReadTable", "dbWriteTable", "dbListTables", "dbExistsTable", "dbRemoveTable", "dbIsValid", "dbHasCompleted", "dbGetStatement", "dbGetRowCount", "dbGetRowsAffected", "transactions", "dbWithTransaction" ) asis_topic(topics, patch_method_doc) ``` DBI/inst/doc/backend.R0000644000176200001440000000542613070016501014104 0ustar liggesusers## ---- echo = FALSE------------------------------------------------------- library(DBI) knitr::opts_chunk$set(collapse = TRUE, comment = "#>") ## ------------------------------------------------------------------------ #' Driver for Kazam database. #' #' @keywords internal #' @export #' @import DBI #' @import methods setClass("KazamDriver", contains = "DBIDriver") ## ------------------------------------------------------------------------ #' @export #' @rdname Kazam-class setMethod("dbUnloadDriver", "KazamDriver", function(drv, ...) { TRUE }) ## ------------------------------------------------------------------------ setMethod("show", "KazamDriver", function(object) { cat("\n") }) ## ------------------------------------------------------------------------ #' @export Kazam <- function() { new("KazamDriver") } Kazam() ## ------------------------------------------------------------------------ #' Kazam connection class. #' #' @export #' @keywords internal setClass("KazamConnection", contains = "DBIConnection", slots = list( host = "character", username = "character", # and so on ptr = "externalptr" ) ) ## ------------------------------------------------------------------------ #' @param drv An object created by \code{Kazam()} #' @rdname Kazam #' @export #' @examples #' \dontrun{ #' db <- dbConnect(RKazam::Kazam()) #' dbWriteTable(db, "mtcars", mtcars) #' dbGetQuery(db, "SELECT * FROM mtcars WHERE cyl == 4") #' } setMethod("dbConnect", "KazamDriver", function(drv, ...) { # ... new("KazamConnection", host = host, ...) }) ## ------------------------------------------------------------------------ #' Kazam results class. #' #' @keywords internal #' @export setClass("KazamResult", contains = "DBIResult", slots = list(ptr = "externalptr") ) ## ------------------------------------------------------------------------ #' Send a query to Kazam. #' #' @export #' @examples #' # This is another good place to put examples setMethod("dbSendQuery", "KazamConnection", function(conn, statement, ...) { # some code new("KazamResult", ...) }) ## ------------------------------------------------------------------------ #' @export setMethod("dbClearResult", "KazamResult", function(res, ...) { # free resources TRUE }) ## ------------------------------------------------------------------------ #' Retrieve records from Kazam query #' @export setMethod("dbFetch", "KazamResult", function(res, n = -1, ...) { ... }) # (optionally) #' Find the database data type associated with an R object #' @export setMethod("dbDataType", "KazamConnection", function(dbObj, obj, ...) { ... }) ## ------------------------------------------------------------------------ #' @export setMethod("dbHasCompleted", "KazamResult", function(res, ...) { }) DBI/inst/doc/DBI-1.html0000644000176200001440000041773613070016501014027 0ustar liggesusers A Common Database Interface (DBI)

A Common Database Interface (DBI)

R-Databases Special Interest Group

16 June 2003

This document describes a common interface between the S language (in its R and S-Plus implementations) and database management systems (DBMS). The interface defines a small set of classes and methods similar in spirit to Perl’s DBI, Java’s JDBC, Python’s DB-API, and Microsoft’s ODBC.

Version

This document describes version 0.1-6 of the database interface API (application programming interface).

Introduction

The database interface (DBI) separates the connectivity to the DBMS into a “front-end” and a “back-end”. Applications use only the exposed “front-end” API. The facilities that communicate with specific DBMS (Oracle, PostgreSQL, etc.) are provided by “device drivers” that get invoked automatically by the S language evaluator. The following example illustrates some of the DBI capabilities:

## Choose the proper DBMS driver and connect to the server

drv <- dbDriver("ODBC")
con <- dbConnect(drv, "dsn", "usr", "pwd")

## The interface can work at a higher level importing tables 
## as data.frames and exporting data.frames as DBMS tables.

dbListTables(con)
dbListFields(con, "quakes")
if(dbExistsTable(con, "new_results"))
   dbRemoveTable(con, "new_results")
dbWriteTable(con, "new_results", new.output)

## The interface allows lower-level interface to the DBMS
res <- dbSendQuery(con, paste(
            "SELECT g.id, g.mirror, g.diam, e.voltage",
            "FROM geom_table as g, elec_measures as e",
            "WHERE g.id = e.id and g.mirrortype = 'inside'",
            "ORDER BY g.diam"))
out <- NULL
while(!dbHasCompleted(res)){
   chunk <- fetch(res, n = 10000)
   out <- c(out, doit(chunk))
}

## Free up resources
dbClearResult(res)
dbDisconnect(con)
dbUnloadDriver(drv)

(only the first 2 expressions are DBMS-specific – all others are independent of the database engine itself).

Individual DBI drivers need not implement all the features we list below (we indicate those that are optional). Furthermore, drivers may extend the core DBI facilities, but we suggest to have these extensions clearly indicated and documented.

The following are the elements of the DBI:

  1. A set of classes and methods (Section [sec:DBIClasses]) that defines what operations are possible and how they are defined, e.g.:

    • connect/disconnect to the DBMS

    • create and execute statements in the DBMS

    • extract results/output from statements

    • error/exception handling

    • information (meta-data) from database objects

    • transaction management (optional)

    Some things are left explicitly unspecified, e.g., authentication and even the query language, although it is hard to avoid references to SQL and relational database management systems (RDBMS).

  2. Drivers

    Drivers are collection of functions that implement the functionality defined above in the context of specific DBMS, e.g., mSQL, Informix.

  3. Data type mappings (Section [sec:data-mappings].)

    Mappings and conversions between DBMS data types and R/S objects. All drivers should implement the “basic” primitives (see below), but may chose to add user-defined conversion function to handle more generic objects (e.g., factors, ordered factors, time series, arrays, images).

  4. Utilities (Section [sec:utilities].)

    These facilities help with details such as mapping of identifiers between S and DBMS (e.g., _ is illegal in R/S names, and . is used for constructing compound SQL identifiers), etc.

DBI Classes and Methods

The following are the main DBI classes. They need to be extended by individual database back-ends (Sybase, Oracle, etc.) Individual drivers need to provide methods for the generic functions listed here (those methods that are optional are so indicated).

Note: Although R releases prior to 1.4 do not have a formal concept of classes, we will use the syntax of the S Version 4 classes and methods (available in R releases 1.4 and later as library methods) to convey precisely the DBI class hierarchy, its methods, and intended behavior.

The DBI classes are DBIObject, DBIDriver, DBIConnection and DBIResult. All these are virtual classes. Drivers define new classes that extend these, e.g., PgSQLDriver, PgSQLConnection, and so on.

Class hierarchy for the DBI. The top two layers are comprised of virtual classes and each lower layer represents a set of driver-specific implementation classes that provide the functionality defined by the virtual classes above.

Class hierarchy for the DBI. The top two layers are comprised of virtual classes and each lower layer represents a set of driver-specific implementation classes that provide the functionality defined by the virtual classes above.

DBIObject:

Virtual class1 that groups all other DBI classes.

DBIDriver:

Virtual class that groups all DBMS drivers. Each DBMS driver extends this class. Typically generator functions instantiate the actual driver objects, e.g., PgSQL, HDF5, BerkeleyDB.

DBIConnection:

Virtual class that encapsulates connections to DBMS.

DBIResult:

Virtual class that describes the result of a DBMS query or statement.

[Q: Should we distinguish between a simple result of DBMS statements e.g., as delete from DBMS queries (i.e., those that generate data).]

The methods format, print, show, dbGetInfo, and summary are defined (and implemented in the DBI package) for the DBIObject base class, thus available to all implementations; individual drivers, however, are free to override them as they see fit.

format(x, ...):

produces a concise character representation (label) for the DBIObject x.

print(x, ...)/show(x):

prints a one-line identification of the object x.

summary(object, ...):

produces a concise description of the object. The default method for DBIObject simply invokes dbGetInfo(dbObj) and prints the name-value pairs one per line. Individual implementations may tailor this appropriately.

dbGetInfo(dbObj, ...):

extracts information (meta-data) relevant for the DBIObject dbObj. It may return a list of key/value pairs, individual meta-data if supplied in the call, or NULL if the requested meta-data is not available.

Hint: Driver implementations may choose to allow an argument what to specify individual meta-data, e.g., dbGetInfo(drv, what = max.connections).

In the next few sub-sections we describe in detail each of these classes and their methods.

Class DBIObject

This class simply groups all DBI classes, and thus all extend it.

Class DBIDriver

This class identifies the database management system. It needs to be extended by individual back-ends (Oracle, PostgreSQL, etc.)

The DBI provides the generator dbDriver(driverName) which simply invokes the function driverName, which in turn instantiates the corresponding driver object.

The DBIDriver class defines the following methods:

driverName:

[meth:driverName] initializes the driver code. The name driverName refers to the actual generator function for the DBMS, e.g., RPgSQL, RODBC, HDF5. The driver instance object is used with dbConnect (see page ) for opening one or possibly more connections to one or more DBMS.

dbListConnections(drv, ...):

list of current connections being handled by the drv driver. May be NULL if there are no open connections. Drivers that do not support multiple connections may return the one open connection.

dbGetInfo(dbObj, ...):

returns a list of name-value pairs of information about the driver.

Hint: Useful entries could include

name:

the driver name (e.g., RODBC, RPgSQL);

driver.version:

version of the driver;

DBI.version:

the version of the DBI that the driver implements, e.g., 0.1-2;

client.version:

of the client DBMS libraries (e.g., version of the libpq library in the case of RPgSQL);

max.connections:

maximum number of simultaneous connections;

plus any other relevant information about the implementation, for instance, how the driver handles upper/lower case in identifiers.

dbUnloadDriver(driverName) (optional):

frees all resources (local and remote) used by the driver. Returns a logical to indicate if it succeeded or not.

Class DBIConnection

This virtual class encapsulates the connection to a DBMS, and it provides access to dynamic queries, result sets, DBMS session management (transactions), etc.

Note: Individual drivers are free to implement single or multiple simultaneous connections.

The methods defined by the DBIConnection class include:

dbConnect(drv, ...):

[meth:dbConnect] creates and opens a connection to the database implemented by the driver drv (see Section [sec:DBIDriver]). Each driver will define what other arguments are required, e.g., dbname or dsn for the database name, user, and password. It returns an object that extends DBIConnection in a driver-specific manner (e.g., the MySQL implementation could create an object of class MySQLConnection that extends DBIConnection).

dbDisconnect(conn, ...):

closes the connection, discards all pending work, and frees resources (e.g., memory, sockets). Returns a logical indicating whether it succeeded or not.

dbSendQuery(conn, statement, ...):

submits one statement to the DBMS. It returns a DBIResult object. This object is needed for fetching data in case the statement generates output (see fetch on page ), and it may be used for querying the state of the operation; see dbGetInfo and other meta-data methods on page .

dbGetQuery(conn, statement, ...):

submit, execute, and extract output in one operation. The resulting object may be a data.frame if the statement generates output. Otherwise the return value should be a logical indicating whether the query succeeded or not.

dbGetException(conn, ...):

returns a list with elements errNum and errMsg with the status of the last DBMS statement sent on a given connection (this information may also be provided by the dbGetInfo meta-data function on the conn object.

Hint: The ANSI SQL-92 defines both a status code and an status message that could be return as members of the list.

dbGetInfo(dbObj, ...):

returns a list of name-value pairs describing the state of the connection; it may return one or more meta-data, the actual driver method allows to specify individual pieces of meta-data (e.g., maximum number of open results/cursors).

Hint: Useful entries could include

dbname:

the name of the database in use;

db.version:

the DBMS server version (e.g., “Oracle 8.1.7 on Solaris”;

host:

host where the database server resides;

user:

user name;

password:

password (is this safe?);

plus any other arguments related to the connection (e.g., thread id, socket or TCP connection type).

dbListResults(conn, ...):

list of DBIResult objects currently active on the connection conn. May be NULL if no result set is active on conn. Drivers that implement only one result set per connection could return that one object (no need to wrap it in a list).

Note: The following are convenience methods that simplify the import/export of (mainly) data.frames. The first five methods implement the core methods needed to attach remote DBMS to the S search path. (For details, see Chambers (1991; Chambers 1998).)

Hint: For relational DBMS these methods may be easily implemented using the core DBI methods dbConnect, dbSendQuery, and fetch, due to SQL reflectance (i.e., one easily gets this meta-data by querying the appropriate tables on the RDBMS).

dbListTables(conn, ...):

returns a character vector (possibly of zero-length) of object (table) names available on the conn connection.

dbReadTable(conn, name, ...):

imports the data stored remotely in the table name on connection conn. Use the field row.names as the row.names attribute of the output data.frame. Returns a data.frame.

[Q: should we spell out how row.names should be created? E.g., use a field (with unique values) as row.names? Also, should dbReadTable reproduce a data.frame exported with dbWriteTable?]

dbWriteTable(conn, name, value, ...):

write the object value (perhaps after coercing it to data.frame) into the remote object name in connection conn. Returns a logical indicating whether the operation succeeded or not.

dbExistsTable(conn, name, ...):

does remote object name exist on conn? Returns a logical.

dbRemoveTable(conn, name, ...):

removes remote object name on connection conn. Returns a logical indicating whether the operation succeeded or not.

dbListFields(conn, name, ...):

returns a character vector listing the field names of the remote table name on connection conn (see dbColumnInfo() for extracting data type on a table).

Note: The following methods deal with transactions and stored procedures. All these functions are optional.

dbCommit(conn, ...)(optional):

commits pending transaction on the connection and returns TRUE or FALSE depending on whether the operation succeeded or not.

dbRollback(conn, ...)(optional):

undoes current transaction on the connection and returns TRUE or FALSE depending on whether the operation succeeded or not.

dbCallProc(conn, storedProc, ...)(optional):

invokes a stored procedure in the DBMS and returns a DBIResult object.

[Stored procedures are not part of the ANSI SQL-92 standard and vary substantially from one RDBMS to another.]

Class DBIResult

This virtual class describes the result and state of execution of a DBMS statement (any statement, query or non-query). The result set res keeps track of whether the statement produces output for R/S, how many rows were affected by the operation, how many rows have been fetched (if statement is a query), whether there are more rows to fetch, etc.

Note: Individual drivers are free to allow single or multiple active results per connection.

[Q: Should we distinguish between results that return no data from those that return data?]

The class DBIResult defines the following methods:

fetch(res, n, ...):

[meth:fetch] fetches the next n elements (rows) from the result set res and return them as a data.frame. A value of n=-1 is interpreted as “return all elements/rows”.

dbClearResult(res, ...):

flushes any pending data and frees all resources (local and remote) used by the object res on both sides of the connection. Returns a logical indicating success or not.

dbGetInfo(dbObj, ...):

returns a name-value list with the state of the result set.

Hint: Useful entries could include

statement:

a character string representation of the statement being executed;

rows.affected:

number of affected records (changed, deleted, inserted, or extracted);

row.count:

number of rows fetched so far;

has.completed:

has the statement (query) finished?

is.select:

a logical describing whether or not the statement generates output;

plus any other relevant driver-specific meta-data.

dbColumnInfo(res, ...):

produces a data.frame that describes the output of a query. The data.frame should have as many rows as there are output fields in the result set, and each column in the data.frame should describe an aspect of the result set field (field name, type, etc.)

Hint: The data.frame columns could include

field.name:

DBMS field label;

field.type:

DBMS field type (implementation-specific);

data.type:

corresponding R/S data type, e.g., integer;

precision/scale:

(as in ODBC terminology), display width and number of decimal digits, respectively;

nullable:

whether the corresponding field may contain (DBMS) NULL values;

plus other driver-specific information.

dbSetDataMappings(flds, ...)(optional):

defines a conversion between internal DBMS data types and R/S classes. We expect the default mappings (see Section [sec:data-mappings]) to be by far the most common ones, but users that need more control may specify a class generator for individual fields in the result set. [This topic needs further discussion.]

Note: The following are convenience methods that extract information from the result object (they may be implemented by invoking dbGetInfo with appropriate arguments).

dbGetStatement(res, ...)(optional):

returns the DBMS statement (as a character string) associated with the result res.

dbGetRowsAffected(res, ...)(optional):

returns the number of rows affected by the executed statement (number of records deleted, modified, extracted, etc.)

dbHasCompleted(res, ...)(optional):

returns a logical that indicates whether the operation has been completed (e.g., are there more records to be fetched?).

dbGetRowCount(res, ...)(optional):

returns the number of rows fetched so far.

Data Type Mappings

The data types supported by databases are different than the data types in R and S, but the mapping between the “primitive” types is straightforward: Any of the many fixed and varying length character types are mapped to R/S character. Fixed-precision (non-IEEE) numbers are mapped into either doubles (numeric) or long (integer). Notice that many DBMS do not follow the so-called IEEE arithmetic, so there are potential problems with under/overflows and loss of precision, but given the R/S primitive types we cannot do too much but identify these situations and warn the application (how?).

By default dates and date-time objects are mapped to character using the appropriate TO_CHAR function in the DBMS (which should take care of any locale information). Some RDBMS support the type CURRENCY or MONEY which should be mapped to numeric (again with potential round off errors). Large objects (character, binary, file, etc.) also need to be mapped. User-defined functions may be specified to do the actual conversion (as has been done in other inter-systems packages2).

Specifying user-defined conversion functions still needs to be defined.

Utilities

The core DBI implementation should make available to all drivers some common basic utilities. For instance:

dbGetDBIVersion:

returns the version of the currently attached DBI as a string.

dbDataType(dbObj, obj, ...):

returns a string with the (approximately) appropriate data type for the R/S object obj. The DBI can implement this following the ANSI-92 standard, but individual drivers may want/need to extend it to make use of DBMS-specific types.

make.db.names(dbObj, snames, ...):

maps R/S names (identifiers) to SQL identifiers replacing illegal characters (as .) by the legal SQL _.

SQLKeywords(dbObj, ...):

returns a character vector of SQL keywords (reserved words). The default method returns the list of .SQL92Keywords, but drivers should update this vector with the DBMS-specific additional reserved words.

isSQLKeyword(dbObj, name, ...):

for each element in the character vector name determine whether or not it is an SQL keyword, as reported by the generic function SQLKeywords. Returns a logical vector parallel to the input object name.

Open Issues and Limitations

There are a number of issues and limitations that the current DBI conscientiously does not address on the interest of simplicity. We do list here the most important ones.

Non-SQL:

Is it realistic to attempt to encompass non-relational databases, like HDF5, Berkeley DB, etc.?

Security:

allowing users to specify their passwords on R/S scripts may be unacceptable for some applications. We need to consider alternatives where users could store authentication on files (perhaps similar to ODBC’s odbc.ini) with more stringent permissions.

Exceptions:

the exception mechanism is a bit too simple, and it does not provide for information when problems stem from the DBMS interface itself. For instance, under/overflow or loss of precision as we move numeric data from DBMS to the more limited primitives in R/S.

Asynchronous communication:

most DBMS support both synchronous and asynchronous communications, allowing applications to submit a query and proceed while the database server process the query. The application is then notified (or it may need to poll the server) when the query has completed. For large computations, this could be very useful, but the DBI would need to specify how to interrupt the server (if necessary) plus other details. Also, some DBMS require applications to use threads to implement asynchronous communication, something that neither R nor S-Plus currently addresses.

SQL scripts:

the DBI only defines how to execute one SQL statement at a time, forcing users to split SQL scripts into individual statements. We need a mechanism by which users can submit SQL scripts that could possibly generate multiple result sets; in this case we may need to introduce new methods to loop over multiple results (similar to Python’s nextResultSet).

BLOBS/CLOBS:

large objects (both character and binary) present some challenges both to R and S-Plus. It is becoming more common to store images, sounds, and other data types as binary objects in DBMS, some of which can be in principle quite large. The SQL-92 ANSI standard allows up to 2 gigabytes for some of these objects. We need to carefully plan how to deal with binary objects.

Transactions:

transaction management is not fully described.

Additional methods:

Do we need any additional methods? (e.g., dbListDatabases(conn), dbListTableIndices(conn, name), how do we list all available drivers?)

Bind variables:

the interface is heavily biased towards queries, as opposed to general purpose database development. In particular we made no attempt to define “bind variables”; this is a mechanism by which the contents of R/S objects are implicitly moved to the database during SQL execution. For instance, the following embedded SQL statement

  /* SQL */
  SELECT * from emp_table where emp_id = :sampleEmployee

would take the vector sampleEmployee and iterate over each of its elements to get the result. Perhaps the DBI could at some point in the future implement this feature.

Resources

The idea of a common interface to databases has been successfully implemented in various environments, for instance:

Java’s Database Connectivity (JDBC) (www.javasoft.com).

In C through the Open Database Connectivity (ODBC) (www.unixodbc.org).

Python’s Database Application Programming Interface (www.python.org).

Perl’s Database Interface (dbi.perl.org).

Chambers, John M. 1991. “Data Management in S.” Bell Labs, Lucent Technologies.

———. 1998. “Database Classes.” Bell Labs, Lucent Technologies.

  1. A virtual class allows us to group classes that share some common characteristics, even if their implementations are radically different.↩

  2. Duncan Temple Lang has volunteered to port the data conversion code found in R-Java, R-Perl, and R-Python packages to the DBI↩

DBI/inst/doc/spec.R0000644000176200001440000000735213070016501013447 0ustar liggesusers## ----echo = FALSE-------------------------------------------------------- library(magrittr) library(xml2) knitr::opts_chunk$set(echo = FALSE) r <- rprojroot::is_r_package$make_fix_file() ## ----error=TRUE---------------------------------------------------------- rd_db <- tools::Rd_db(dir = r()) Links <- tools::findHTMLlinks() html_topic <- function(name) { rd <- rd_db[[paste0(name, ".Rd")]] conn <- textConnection(NULL, "w") on.exit(close(conn)) #tools::Rd2HTML(rd, conn, Links = Links) tools::Rd2HTML(rd, conn) textConnectionValue(conn) } xml_topic <- function(name, patcher) { html <- html_topic(name) x <- read_html(paste(html, collapse = "\n")) # No idea why this is necessary when embedding HTML in Markdown codes <- x %>% xml_find_all("//code[contains(., '$')]") xml_text(codes) <- gsub("[$]", "\\\\$", xml_text(codes)) xx <- x %>% xml_find_first("/html/body") xx %>% xml_find_first("//table") %>% xml_remove() patcher(xx) } asis_topic <- function(name, patcher = identity) { xml <- lapply(name, xml_topic, patcher = patcher) asis <- sapply(xml, as.character) %>% paste(collapse = "\n") knitr::asis_output(asis) } patch_package_doc <- function(x) { x %>% xml_find_first("//h3") %>% xml_remove remove_see_also_section(x) remove_authors_section(x) x } move_contents_of_usage_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 usage_contents <- x %>% xml_find_all( "//h3[.='Usage']/following-sibling::node() [not(self::h3)] [count(preceding-sibling::h3)=2]") usage_text <- usage_contents %>% xml_find_first("//pre") %>% xml_text h3 <- x %>% xml_find_first("//h3") intro_text <- read_xml( paste0( "

This section describes the behavior of the following method", if (length(grep("[(]", strsplit(usage_text, "\n")[[1]])) > 1) "s" else "", ":

") ) xml_add_sibling( h3, intro_text, .where = "before") lapply(usage_contents, xml_add_sibling, .x = h3, .copy = FALSE, .where = "before") x %>% xml_find_first("//h3[.='Usage']") %>% xml_remove x } move_additional_arguments_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error additional_arguments <- x %>% xml_find_all( "//h3[.='Additional arguments'] | //h3[.='Additional arguments']/following-sibling::node()[following-sibling::h3]") after_arg <- x %>% xml_find_first("//h3[text()='Arguments']/following-sibling::h3") lapply(additional_arguments, xml_add_sibling, .x = after_arg, .copy = FALSE, .where = "before") x } remove_see_also_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error x %>% xml_find_all( "//h3[.='See Also'] | //h3[.='See Also']/following-sibling::node()[following-sibling::h3]") %>% xml_remove() x } remove_authors_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error x %>% xml_find_all( "//h3[.='Author(s)'] | //h3[.='Author(s)']/following-sibling::node()[following-sibling::h3]") %>% xml_remove() x } patch_method_doc <- function(x) { move_contents_of_usage_section(x) remove_see_also_section(x) move_additional_arguments_section(x) x } asis_topic("DBI-package", patch_package_doc) topics <- c( "dbDataType", "dbConnect", "dbDisconnect", "dbSendQuery", "dbFetch", "dbClearResult", "dbBind", "dbGetQuery", "dbSendStatement", "dbExecute", "dbQuoteString", "dbQuoteIdentifier", "dbReadTable", "dbWriteTable", "dbListTables", "dbExistsTable", "dbRemoveTable", "dbIsValid", "dbHasCompleted", "dbGetStatement", "dbGetRowCount", "dbGetRowsAffected", "transactions", "dbWithTransaction" ) asis_topic(topics, patch_method_doc) DBI/inst/doc/DBI-proposal.Rmd0000644000176200001440000006646313070016501015301 0ustar liggesusers--- title: "A Common Interface to Relational Databases from R and S -- A Proposal" author: "David James" date: "March 16, 2000" output: rmarkdown::html_vignette bibliography: biblio.bib vignette: > %\VignetteIndexEntry{A Common Interface to Relational Databases from R and S -- A Proposal} %\VignetteEngine{knitr::rmarkdown} --- For too long S and similar data analysis environments have lacked good interfaces to relational database systems (RDBMS). For the last twenty years or so these RDBMS have evolved into highly optimized client-server systems for data storage and manipulation, and currently they serve as repositories for most of the business, industrial, and research “raw” data that analysts work with. Other analysis packages, such as SAS, have traditionally provided good data connectivity, but S and GNU R have relied on intermediate text files as means of importing data (but see @R.imp-exp and @R-dbms.) Although this simple approach works well for relatively modest amounts of mostly static data, it does not scale up to larger amounts of data distributed over machines and locations, nor does it scale up to data that is highly dynamic – situations that are becoming increasingly common. We want to propose a common interface between R/S and RDBMS that would allow users to access data stored on database servers in a uniform and predictable manner irrespective of the database engine. The interface defines a small set of classes and methods similar in spirit to Python’s DB-API, Java’s JDBC, Microsoft’s ODBC, Perl’s DBI, etc., but it conforms to the “whole-object” philosophy so natural in S and R. # Computing with Distributed Data {#sec:distr} As data analysts, we are increasingly faced with the challenge of larger data sources distributed over machines and locations; most of these data sources reside in relational database management systems (RDBMS). These relational databases represent a mature client-server distributed technology that we as analysts could be exploiting more that we’ve done in the past. The relational technology provides a well-defined standard, the ANSI SQL-92 @sql92, both for defining and manipulating data in a highly optimized fashion from virtually any application. In contrast, S and Splus have provided somewhat limited tools for coping with the challenges of larger and distributed data sets (Splus does provide an `import` function to import from databases, but it is quite limited in terms of SQL facilities). The R community has been more resourceful and has developed a number of good libraries for connecting to mSQL, MySQL, PostgreSQL, and ODBC; each library, however, has defined its own interface to each database engine a bit differently. We think it would be to everybody’s advantage to coordinate the definition of a common interface, an effort not unlike those taken in the Python and Perl communities. The goal of a common, seamless access to distributed data is a modest one in our evolution towards a fully distributed computing environment. We recognize the greater goal of distributed computing as the means to fully integrate diverse systems – not just databases – into a truly flexible analysis environment. Good connectivity to databases, however, is of immediate necessity both in practical terms and as a means to help us transition from monolithic, self-contained systems to those in which computations, not only the data, can be carried out in parallel over a wide number of computers and/or systems @duncan2000. Issues of reliability, security, location transparency, persistence, etc., will be new to most of us and working with distributed data may provide a more gradual change to ease in the ultimate goal of full distributed computing. # A Common Interface {#sec:rs-dbi} We believe that a common interface to databases can help users easily access data stored in RDBMS. A common interface would describe, in a uniform way, how to connect to RDBMS, extract meta-data (such as list of available databases, tables, etc.) as well as a uniform way to execute SQL statements and import their output into R and S. The current emphasis is on querying databases and not so much in a full low-level interface for database development as in JDBC or ODBC, but unlike these, we want to approach the interface from the “whole-object” perspective @S4 so natural to R/S and Python – for instance, by fetching all fields and records simultaneously into a single object. The basic idea is to split the interface into a front-end consisting of a few classes and generic functions that users invoke and a back-end set of database-specific classes and methods that implement the actual communication. (This is a very well-known pattern in software engineering, and another good verbatim is the device-independent graphics in R/S where graphics functions produce similar output on a variety of different devices, such X displays, Postscript, etc.) The following verbatim shows the front-end: ``` > mgr <- dbManager("Oracle") > con <- dbConnect(mgr, user = "user", passwd = "passwd") > rs <- dbExecStatement(con, "select fld1, fld2, fld3 from MY_TABLE") > tbls <- fetch(rs, n = 100) > hasCompleted(rs) [1] T > close(rs) > rs <- dbExecStatement(con, "select id_name, q25, q50 from liv2") > res <- fetch(rs) > getRowCount(rs) [1] 73 > close(con) ``` Such scripts should work with other RDBMS (say, MySQL) by replacing the first line with ``` > mgr <- dbManager("MySQL") ``` ## Interface Classes {#sec:rs-dbi-classes} The following are the main RS-DBI classes. They need to be extended by individual database back-ends (MySQL, Oracle, etc.) `dbManager` : Virtual class[^2] extended by actual database managers, e.g., Oracle, MySQL, Informix. `dbConnection` : Virtual class that captures a connection to a database instance[^3]. `dbResult` : Virtual class that describes the result of an SQL statement. `dbResultSet` : Virtual class, extends `dbResult` to fully describe the output of those statements that produce output records, i.e., `SELECT` (or `SELECT`-like) SQL statement. All these classes should implement the methods `show`, `describe`, and `getInfo`: `show` : (`print` in R) prints a one-line identification of the object. `describe` : prints a short summary of the meta-data of the specified object (like `summary` in R/S). `getInfo` : takes an object of one of the above classes and a string specifying a meta-data item, and it returns the corresponding information (`NULL` if unavailable). > mgr <- dbManager("MySQL") > getInfo(mgr, "version") > con <- dbConnect(mgr, ...) > getInfo(con, "type") The reason we implement the meta-data through `getInfo` in this way is to simplify the writing of database back-ends. We don’t want to overwhelm the developers of drivers (ourselves, most likely) with hundreds of methods as in the case of JDBC. In addition, the following methods should also be implemented: `getDatabases` : lists all available databases known to the `dbManager`. `getTables` : lists tables in a database. `getTableFields` : lists the fields in a table in a database. `getTableIndices` : lists the indices defined for a table in a database. These methods may be implemented using the appropriate `getInfo` method above. In the next few sections we describe in detail each of these classes and their methods. ### Class `dbManager` {#sec:dbManager} This class identifies the relational database management system. It needs to be extended by individual back-ends (Oracle, PostgreSQL, etc.) The `dbManager` class defines the following methods: `load` : initializes the driver code. We suggest having the generator, `dbManager(driver)`, automatically load the driver. `unload` : releases whatever resources the driver is using. `getVersion` : returns the version of the RS-DBI currently implemented, plus any other relevant information about the implementation itself and the RDBMS being used. ### Class `dbConnection` {#sec:dbConnection} This virtual class captures a connection to a RDBMS, and it provides access to dynamic SQL, result sets, RDBMS session management (transactions), etc. Note that the `dbManager` may or may not allow multiple simultaneous connections. The methods it defines include: `dbConnect` : opens a connection to the database `dbname`. Other likely arguments include `host`, `user`, and `password`. It returns an object that extends `dbConnection` in a driver-specific manner (e.g., the MySQL implementation creates a connection of class `MySQLConnection` that extends `dbConnection`). Note that we could separate the steps of connecting to a RDBMS and opening a database there (i.e., opening an *instance*). For simplicity we do the 2 steps in this method. If the user needs to open another instance in the same RDBMS, just open a new connection. `close` : closes the connection and discards all pending work. `dbExecStatement` : submits one SQL statement. It returns a `dbResult` object, and in the case of a `SELECT` statement, the object also inherits from `dbResultSet`. This `dbResultSet` object is needed for fetching the output rows of `SELECT` statements. The result of a non-`SELECT` statement (e.g., `UPDATE, DELETE, CREATE, ALTER`, ...) is defined as the number of rows affected (this seems to be common among RDBMS). `commit` : commits pending transaction (optional). `rollback` : undoes current transaction (optional). `callProc` : invokes a stored procedure in the RDBMS (tentative). Stored procedures are *not* part of the ANSI SQL-92 standard and possibly vary substantially from one RDBMS to another. For instance, Oracle seems to have a fairly decent implementation of stored procedures, but MySQL currently does not support them. `dbExec` : submit an SQL “script” (multiple statements). May be implemented by looping with `dbExecStatement`. `dbNextResultSet` : When running SQL scripts (multiple statements), it closes the current result set in the `dbConnection`, executes the next statement and returns its result set. ### Class `dbResult` {#sec:dbResult} This virtual class describes the result of an SQL statement (any statement) and the state of the operation. Non-query statements (e.g., `CREATE`, `UPDATE`, `DELETE`) set the “completed” state to 1, while `SELECT` statements to 0. Error conditions set this slot to a negative number. The `dbResult` class defines the following methods: `getStatement` : returns the SQL statement associated with the result set. `getDBConnection` : returns the `dbConnection` associated with the result set. `getRowsAffected` : returns the number of rows affected by the operation. `hasCompleted` : was the operation completed? `SELECT`’s, for instance, are not completed until their output rows are all fetched. `getException` : returns the status of the last SQL statement on a given connection as a list with two members, status code and status description. ### Class `dbResultSet` {#sec:dbResultSet} This virtual class extends `dbResult`, and it describes additional information from the result of a `SELECT` statement and the state of the operation. The `completed` state is set to 0 so long as there are pending rows to fetch. The `dbResultSet` class defines the following additional methods: `getRowCount` : returns the number of rows fetched so far. `getNullOk` : returns a logical vector with as many elements as there are fields in the result set, each element describing whether the corresponding field accepts `NULL` values. `getFields` : describes the `SELECT`ed fields. The description includes field names, RDBMS internal data types, internal length, internal precision and scale, null flag (i.e., column allows `NULL`’s), and corresponding S classes (which can be over-ridden with user-provided classes). The current MySQL and Oracle implementations define a `dbResultSet` as a named list with the following elements: `connection`: : the connection object associated with this result set; `statement`: : a string with the SQL statement being processed; `description`: : a field description `data.frame` with as many rows as there are fields in the `SELECT` output, and columns specifying the `name`, `type`, `length`, `precision`, `scale`, `Sclass` of the corresponding output field. `rowsAffected`: : the number of rows that were affected; `rowCount`: : the number of rows so far fetched; `completed`: : a logical value describing whether the operation has completed or not. `nullOk`: : a logical vector specifying whether the corresponding column may take NULL values. The methods above are implemented as accessor functions to this list in the obvious way. `setDataMappings` : defines a conversion between internal RDBMS data types and R/S classes. We expect the default mappings to be by far the most common ones, but users that need more control may specify a class generator for individual fields in the result set. (See Section [sec:mappings] for details.) `close` : closes the result set and frees resources both in R/S and the RDBMS. `fetch` : extracts the next `max.rec` records (-1 means all). ## Data Type Mappings {#sec:mappings} The data types supported by databases are slightly different than the data types in R and S, but the mapping between them is straightforward: Any of the many fixed and varying length character types are mapped to R/S `character`. Fixed-precision (non-IEEE) numbers are mapped into either doubles (`numeric`) or long (`integer`). Dates are mapped to character using the appropriate `TO_CHAR` function in the RDBMS (which should take care of any locale information). Some RDBMS support the type `CURRENCY` or `MONEY` which should be mapped to `numeric`. Large objects (character, binary, file, etc.) also need to be mapped. User-defined functions may be specified to do the actual conversion as follows: 1. run the query (either with `dbExec` or `dbExecStatement`): > rs <- dbExecStatement(con, "select whatever-You-need") 2. extract the output field definitions > flds <- getFields(rs) 3. replace the class generator in the, say 3rd field, by the user own generator: > flds[3, "Sclass"] # default mapping [1] "character" by > flds[3, "Sclass"] <- "myOwnGeneratorFunction" 4. set the new data mapping prior to fetching > setDataMappings(resutlSet, flds) 5. fetch the rows and store in a `data.frame` > data <- fetch(resultSet) ## Open Issues {#sec:open-issues} We may need to provide some additional utilities, for instance to convert dates, to escape characters such as quotes and slashes in query strings, to strip excessive blanks from some character fields, etc. We need to decide whether we provide hooks so these conversions are done at the C level, or do all the post-processing in R or S. Another issue is what kind of data object is the output of an SQL query. Currently the MySQL and Oracle implementations return data as a `data.frame`; data frames have the slight inconvenience that they automatically re-label the fields according to R/S syntax, changing the actual RDBMS labels of the variables; the issue of non-numeric data being coerced into factors automatically “at the drop of a hat” (as someone in s-news wrote) is also annoying. The execution of SQL scripts is not fully described. The method that executes scripts could run individual statements without returning until it encounters a query (`SELECT`-like) statement. At that point it could return that one result set. The application is then responsible for fetching these rows, and then for invoking `dbNextResultSet` on the opened `dbConnection` object to repeat the `dbExec`/`fetch` loop until it encounters the next `dbResultSet`. And so on. Another (potentially very expensive) alternative would be to run all statements sequentially and return a list of `data.frame`s, each element of the list storing the result of each statement. Binary objects and large objects present some challenges both to R and S. It is becoming more common to store images, sounds, and other data types as binary objects in RDBMS, some of which can be in principle quite large. The SQL-92 ANSI standard allows up to 2 gigabytes for some of these objects. We need to carefully plan how to deal with binary objects – perhaps tentatively not in full generality. Large objects could be fetched by repeatedly invoking a specified R/S function that takes as argument chunks of a specified number of raw bytes. In the case of S4 (and Splus5.x) the RS-DBI implementation can write into an opened connection for which the user has defined a reader (but can we guarantee that we won’t overflow the connection?). In the case of R it is not clear what data type binary large objects (BLOB) should be mapped into. ## Limitations {#sec:limitations} These are some of the limitations of the current interface definition: - we only allow one SQL statement at a time, forcing users to split SQL scripts into individual statements; - transaction management is not fully described; - the interface is heavily biased towards queries, as opposed to general purpose database development. In particular we made no attempt to define “bind variables”; this is a mechanism by which the contents of S objects are implicitly moved to the database during SQL execution. For instance, the following embedded SQL statement /* SQL */ SELECT * from emp_table where emp_id = :sampleEmployee would take the vector `sampleEmployee` and iterate over each of its elements to get the result. Perhaps RS-DBI could at some point in the future implement this feature. # Other Approaches The high-level, front-end description of RS-DBI is the more critical aspect of the interface. Details on how to actually implement this interface may change over time. The approach described in this document based on one back-end driver per RDBMS is reasonable, but not the only approach – we simply felt that a simpler approach based on well-understood and self-contained tools (R, S, and C API’s) would be a better start. Nevertheless we want to briefly mention a few alternatives that we considered and tentatively decided against, but may quite possibly re-visit in the near future. ## Open Database Connectivity (ODBC) {#sec:odbc} The ODBC protocol was developed by Microsoft to allow connectivity among C/C++ applications and RDBMS. As you would expect, originally implementations of the ODBC were only available under Windows environments. There are various effort to create a Unix implementation (see [the Unix ODBC](http://www.unixodbc.org/) web-site and @odbc.lj). This approach looks promising because it allows us to write only one back-end, instead of one per RDBMS. Since most RDBMS already provide ODBC drivers, this could greatly simplify development. Unfortunately, the Unix implementation of ODBC was not mature enough at the time we looked at it, a situation we expect will change in the next year or so. At that point we will need to re-evaluate it to make sure that such an ODBC interface does not penalize the interface in terms of performance, ease of use, portability among the various Unix versions, etc. ## Java Database Connectivity (JDBC) {#sec:jdbc} Another protocol, the Java database connectivity, is very well-done and supported by just about every RDBMS. The issue with JDBC is that as of today neither S nor R (which are written in C) interfaces cleanly with Java. There are several efforts (some in a quite fairly advanced state) to allow S and R to invoke Java methods. Once this interface is widely available in Splus5x and R we will need to re-visit this issue again and study the performance, usability, etc., of JDBC as a common back-end to the RS-DBI. ## CORBA and a 3-tier Architecture {#sec:corba} Yet another approach is to move the interface to RDBMS out of R and S altogether into a separate system or server that would serve as a proxy between R/S and databases. The communication to this middle-layer proxy could be done through CORBA [@s-corba.98, @corba:siegel.96], Java’s RMI, or some other similar technology. Such a design could be very flexible, but the CORBA facilities both in R and S are not widely available yet, and we do not know whether this will be made available to Splus5 users from MathSoft. Also, my experience with this technology is rather limited. On the other hand, this 3-tier architecture seem to offer the most flexibility to cope with very large distributed databases, not necessarily relational. # Resources {#sec:resources} The latest documentation and software on the RS-DBI was available at www.omegahat.net (link dead now: `http://www.omegahat.net/contrib/RS-DBI/index.html`). The R community has developed interfaces to some databases: [RmSQL](https://cran.r-project.org/src/contrib/Archive/RmSQL/) is an interface to the [mSQL](http://www.Hughes.com.au) database written by Torsten Hothorn; [RPgSQL](http://www.nceas.ucsb.edu/~keitt/R) is an interface to [PostgreSQL](http://www.postgreSQL.org) and was written by Timothy H. Keitt; [RODBC](http://www.stats.ox.ac.uk/pub/bdr) is an interface to ODBC, and it was written by [Michael Lapsley](mailto:mlapsley@sthelier.sghms.ac.uk). (For more details on all these see @R.imp-exp.) The are R and S-Plus interfaces to [MySQL](http://www.mysql.org) that follow the propose RS-DBI API described here; also, there’s an S-Plus interface SOracle @RS-Oracle to [Oracle](http://www.oracle.com) (we expect to have an R implementation soon.) The idea of a common interface to databases has been successfully implemented in Java’s Database Connectivity (JDBC) ([www.javasoft.com](http://www.javasoft.com/products/jdbc/index.html)), in C through the Open Database Connectivity (ODBC) ([www.unixodbc.org](http://www.unixodbc.org/)), in Python’s Database Application Programming Interface ([www.python.org](http://www.python.org)), and in Perl’s Database Interface ([www.cpan.org](http://www.cpan.org)). # Acknowledgements The R/S database interface came about from suggestions, comments, and discussions with [John M. Chambers](mailto:jmc@research.bell-labs.com) and [Duncan Temple Lang](mailto:duncan@research.bell-labs.com) in the context of the Omega Project for Statistical Computing. [Doug Bates](mailto:bates@stat.wisc.edu) and [Saikat DebRoy](mailto:saikat@stat.wisc.edu) ported (and greatly improved) the first MySQL implementation to R. # The S Version 4 Definitions The following code is meant to serve as a detailed description of the R/S to database interface. We decided to use S4 (instead of R or S version 3) because its clean syntax help us to describe easily the classes and methods that form the RS-DBI, and also to convey the inter-class relationships. ```R ## Define all the classes and methods to be used by an ## implementation of the RS-DataBase Interface. Mostly, ## these classes are virtual and each driver should extend ## them to provide the actual implementation. ## Class: dbManager ## This class identifies the DataBase Management System ## (Oracle, MySQL, Informix, PostgreSQL, etc.) setClass("dbManager", VIRTUAL) setGeneric("load", def = function(dbMgr,...) standardGeneric("load") ) setGeneric("unload", def = function(dbMgr,...) standardGeneric("unload") ) setGeneric("getVersion", def = function(dbMgr,...) standardGeneric("getVersion") ) ## Class: dbConnections ## This class captures a connection to a database instance. setClass("dbConnection", VIRTUAL) setGeneric("dbConnection", def = function(dbMgr, ...) standardGeneric("dbConnection") ) setGeneric("dbConnect", def = function(dbMgr, ...) standardGeneric("dbConnect") ) setGeneric("dbExecStatement", def = function(con, statement, ...) standardGeneric("dbExecStatement") ) setGeneric("dbExec", def = function(con, statement, ...) standardGeneric("dbExec") ) setGeneric("getResultSet", def = function(con, ..) standardGeneric("getResultSet") ) setGeneric("commit", def = function(con, ...) standardGeneric("commit") ) setGeneric("rollback", def = function(con, ...) standardGeneric("rollback") ) setGeneric("callProc", def = function(con, ...) standardGeneric("callProc") ) setMethod("close", signature = list(con="dbConnection", type="missing"), def = function(con, type) NULL ) ## Class: dbResult ## This is a base class for arbitrary results from the RDBMS ## (INSERT, UPDATE, DELETE). SELECTs (and SELECT-like) ## statements produce "dbResultSet" objects, which extend ## dbResult. setClass("dbResult", VIRTUAL) setMethod("close", signature = list(con="dbResult", type="missing"), def = function(con, type) NULL ) ## Class: dbResultSet ## Note that we define a resultSet as the result of a ## SELECT SQL statement. setClass("dbResultSet", "dbResult") setGeneric("fetch", def = function(resultSet,n,...) standardGeneric("fetch") ) setGeneric("hasCompleted", def = function(object, ...) standardGeneric("hasCompleted") ) setGeneric("getException", def = function(object, ...) standardGeneric("getException") ) setGeneric("getDBconnection", def = function(object, ...) standardGeneric("getDBconnection") ) setGeneric("setDataMappings", def = function(resultSet, ...) standardGeneric("setDataMappings") ) setGeneric("getFields", def = function(object, table, dbname, ...) standardGeneric("getFields") ) setGeneric("getStatement", def = function(object, ...) standardGeneric("getStatement") ) setGeneric("getRowsAffected", def = function(object, ...) standardGeneric("getRowsAffected") ) setGeneric("getRowCount", def = function(object, ...) standardGeneric("getRowCount") ) setGeneric("getNullOk", def = function(object, ...) standardGeneric("getNullOk") ) ## Meta-data: setGeneric("getInfo", def = function(object, ...) standardGeneric("getInfo") ) setGeneric("describe", def = function(object, verbose=F, ...) standardGeneric("describe") ) setGeneric("getCurrentDatabase", def = function(object, ...) standardGeneric("getCurrentDatabase") ) setGeneric("getDatabases", def = function(object, ...) standardGeneric("getDatabases") ) setGeneric("getTables", def = function(object, dbname, ...) standardGeneric("getTables") ) setGeneric("getTableFields", def = function(object, table, dbname, ...) standardGeneric("getTableFields") ) setGeneric("getTableIndices", def = function(object, table, dbname, ...) standardGeneric("getTableIndices") ) ``` [^2]: A virtual class allows us to group classes that share some common functionality, e.g., the virtual class “`dbConnection`” groups all the connection implementations by Informix, Ingres, DB/2, Oracle, etc. Although the details will vary from one RDBMS to another, the defining characteristic of these objects is what a virtual class captures. R and S version 3 do not explicitly define virtual classes, but they can easily implement the idea through inheritance. [^3]: The term “database” is sometimes (confusingly) used both to denote the RDBMS, such as Oracle, MySQL, and also to denote a particular database instance under a RDBMS, such as “opto” or “sales” databases under the same RDBMS. DBI/tests/0000755000176200001440000000000012665571275012032 5ustar liggesusersDBI/tests/testthat.R0000644000176200001440000000004312665571275014012 0ustar liggesuserslibrary(testthat) test_check("DBI")DBI/tests/testthat/0000755000176200001440000000000013070027747013661 5ustar liggesusersDBI/tests/testthat/test-sql-df.R0000644000176200001440000000041012752711155016141 0ustar liggesuserscontext("sqlData") test_that("NAs turn in NULLs", { df <- data.frame( x = c(1, NA), y = c("a", NA), stringsAsFactors = FALSE ) sql_df <- sqlData(ANSI(), df) expect_equal(sql_df$x, c("1", "NULL")) expect_equal(sql_df$y, c("'a'", "NULL")) }) DBI/tests/testthat/test-quote.R0000644000176200001440000000057313055221643016115 0ustar liggesuserscontext("quote") test_that("identifier", { expect_equal(dbQuoteIdentifier(ANSI(), character()), SQL(character())) expect_equal(dbQuoteIdentifier(ANSI(), "a"), SQL('"a"')) expect_equal(dbQuoteIdentifier(ANSI(), "a b"), SQL('"a b"')) expect_equal(dbQuoteIdentifier(ANSI(), SQL('"a"')), SQL('"a"')) expect_equal(dbQuoteIdentifier(ANSI(), SQL('"a b"')), SQL('"a b"')) }) DBI/tests/testthat/test-data-type.R0000644000176200001440000000032213027447303016642 0ustar liggesuserscontext("dbDataType") test_that("dbDataType works on a data frame", { df <- data.frame(x = 1:10, y = runif(10)) types <- dbDataType(MockDriver(), df) expect_equal(types, c(x = "INT", y = "DOUBLE")) }) DBI/tests/testthat/helper-dummy.R0000644000176200001440000000037712752711155016422 0ustar liggesusersMockObject <- setClass("MockObject", contains = "DBIObject") MockDriver <- setClass("MockDriver", contains = "DBIDriver") MockConnection <- setClass("MockConnection", contains = "DBIConnection") MockResult <- setClass("MockResult", contains = "DBIResult")DBI/tests/testthat/test-rownames.R0000644000176200001440000000217712752711155016622 0ustar liggesuserscontext("Rowname translation") test_that("logical row names uses default name", { df <- data.frame(x = c(a = 1)) expect_equal(sqlRownamesToColumn(df, NA)$row_name, "a") expect_equal(sqlRownamesToColumn(df, T)$row_name, "a") expect_equal(sqlRownamesToColumn(df, F)$row_name, NULL) }) test_that("character row names uses supplied name", { df <- data.frame(x = c(a = 1)) expect_equal(sqlRownamesToColumn(df, "x")$x, "a") }) test_that("no rownames in input gives no rownames in output", { df <- data.frame(x = 1) expect_equal(sqlRownamesToColumn(df, NA)$row_name, NULL) }) test_that("guess identify of row_names columns", { df <- data.frame(row_names = "a", x = 1, stringsAsFactors = FALSE) expect_equal(row.names(sqlColumnToRownames(df, NA)), "a") expect_equal(row.names(sqlColumnToRownames(df, TRUE)), "a") expect_equal(row.names(sqlColumnToRownames(df, FALSE)), "1") }) test_that("override identify of row_names column", { df <- data.frame(x = 1, y = "a", stringsAsFactors = FALSE) expect_equal(row.names(sqlColumnToRownames(df, "y")), "a") expect_error(row.names(sqlColumnToRownames(df, "z")), "not present") }) DBI/tests/testthat/test-quoting.R0000644000176200001440000000067313027447303016451 0ustar liggesuserscontext("Quoting") test_that("NA becomes NULL", { expect_equal(dbQuoteString(ANSI(), NA_character_), SQL("NULL")) }) test_that("strings surrounded by '", { expect_equal(dbQuoteString(ANSI(), "x"), SQL("'x'")) }) test_that("single quotes are doubled surrounded by '", { expect_equal(dbQuoteString(ANSI(), "It's"), SQL("'It''s'")) }) test_that("special chars are escaped", { expect_equal(dbQuoteString(ANSI(), "\n"), SQL("'\n'")) }) DBI/tests/testthat/test-interpolate.R0000644000176200001440000000433513054310030017272 0ustar liggesuserscontext("sqlInterpolate") test_that("parameter names matched", { expect_equal( sqlInterpolate(ANSI(), "?a ?b", a = 1, b = 2), SQL("1 2") ) expect_equal( sqlInterpolate(ANSI(), "?a ?b", b = 2, a = 1), SQL("1 2") ) expect_equal( sqlInterpolate(ANSI(), "?a ?b", b = 2, .dots = list(a = 1)), SQL("1 2") ) expect_equal( sqlInterpolate(ANSI(), "?a ?b", .dots = list(a = 1, b = 2)), SQL("1 2") ) }) test_that("parameters in strings are ignored", { expect_equal( sqlInterpolate(ANSI(), "'?a'"), SQL("'?a'") ) }) test_that("parameters in comments are ignored", { expect_equal( sqlInterpolate(ANSI(), "-- ?a"), SQL("-- ?a") ) }) test_that("strings are quoted", { expect_equal( sqlInterpolate(ANSI(), "?a", a = "abc"), SQL("'abc'") ) }) test_that("some more complex case works as well", { expect_equal( sqlInterpolate(ANSI(), "asdf ?faa /*fdsa'zsc' */ qwer 'wer' \"bnmvbn\" -- Zc \n '234' ?fuu -- ?bar", faa = "abc", fuu=42L), SQL("asdf 'abc' /*fdsa'zsc' */ qwer 'wer' \"bnmvbn\" -- Zc \n '234' 42 -- ?bar") ) }) test_that("escaping quotes with doubling works", { expect_equal( sqlInterpolate(ANSI(), "'this is a single '' one ?quoted string' ?bar ", bar=42), SQL("'this is a single '' one ?quoted string' 42 ") ) }) test_that("corner cases work", { expect_equal( sqlInterpolate(ANSI(), ""), SQL("") ) expect_error( sqlInterpolate(ANSI(), "?"), "Length 0 variable" ) expect_equal( sqlInterpolate(ANSI(), "?a", a = 1), SQL("1") ) expect_equal( sqlInterpolate(ANSI(), "\"\""), SQL("\"\"") ) expect_error( sqlInterpolate(ANSI(), "\""), "Unterminated literal" ) expect_equal( sqlInterpolate(ANSI(), "?a\"\"?b", a = 1, b = 2), SQL("1\"\"2") ) expect_equal( sqlInterpolate(ANSI(), "--"), SQL("--") ) expect_error( sqlInterpolate(ANSI(), "/*"), "Unterminated comment" ) # Test escaping rules expect_identical( sqlParseVariablesImpl( "?a '?b\\'?c' ?d '''' ?e", list( sqlQuoteSpec("'", "'", escape = "\\", doubleEscape = FALSE) ), list( ) ), list( start = c(1L, 13L, 21L), end = c(2L, 14L, 22L) ) ) }) DBI/tests/testthat/test-methods.R0000644000176200001440000000105213054310030016400 0ustar liggesuserscontext("methods") expect_ellipsis <- function(name, method) { sym <- as.name(name) eval(bquote({ .(sym) <- method expect_true("..." %in% names(formals(.(sym)))) })) } test_that("all methods have ellipsis", { symbols <- ls(env = asNamespace("DBI")) objects <- mget(symbols, env = asNamespace("DBI"), mode = "function", ifnotfound = rep(list(NULL), length(symbols))) is_method <- vapply(objects, inherits, "standardGeneric", FUN.VALUE = logical(1L)) methods <- objects[is_method] Map(expect_ellipsis, names(methods), methods) }) DBI/NAMESPACE0000644000176200001440000000352513055244744012104 0ustar liggesusers# Generated by roxygen2: do not edit by hand export(.SQL92Keywords) export(ANSI) export(SQL) export(SQLKeywords) export(dbBegin) export(dbBind) export(dbBreak) export(dbCallProc) export(dbClearResult) export(dbColumnInfo) export(dbCommit) export(dbConnect) export(dbDataType) export(dbDisconnect) export(dbDriver) export(dbExecute) export(dbExistsTable) export(dbFetch) export(dbGetDBIVersion) export(dbGetException) export(dbGetInfo) export(dbGetQuery) export(dbGetRowCount) export(dbGetRowsAffected) export(dbGetStatement) export(dbHasCompleted) export(dbIsValid) export(dbListConnections) export(dbListFields) export(dbListResults) export(dbListTables) export(dbQuoteIdentifier) export(dbQuoteString) export(dbReadTable) export(dbRemoveTable) export(dbRollback) export(dbSendQuery) export(dbSendStatement) export(dbSetDataMappings) export(dbUnloadDriver) export(dbWithTransaction) export(dbWriteTable) export(fetch) export(isSQLKeyword) export(isSQLKeyword.default) export(make.db.names) export(make.db.names.default) export(print.list.pairs) export(sqlAppendTable) export(sqlAppendTableTemplate) export(sqlColumnToRownames) export(sqlCommentSpec) export(sqlCreateTable) export(sqlData) export(sqlInterpolate) export(sqlParseVariables) export(sqlParseVariablesImpl) export(sqlQuoteSpec) export(sqlRownamesToColumn) exportClasses(DBIConnection) exportClasses(DBIDriver) exportClasses(DBIObject) exportClasses(DBIResult) exportClasses(SQL) exportMethods(dbDataType) exportMethods(dbExecute) exportMethods(dbFetch) exportMethods(dbGetQuery) exportMethods(dbQuoteIdentifier) exportMethods(dbQuoteString) exportMethods(dbReadTable) exportMethods(dbSendStatement) exportMethods(dbWithTransaction) exportMethods(show) exportMethods(sqlAppendTable) exportMethods(sqlCreateTable) exportMethods(sqlData) exportMethods(sqlInterpolate) exportMethods(sqlParseVariables) import(methods) DBI/NEWS.md0000644000176200001440000002567213070015234011755 0ustar liggesusers# DBI 0.6-1 (2017-04-01) - Fix `dbReadTable()` for backends that do not provide their own implementation (#171). # DBI 0.6 (2017-03-08) - Interface changes - Deprecated `dbDriver()` and `dbUnloadDriver()` by documentation (#21). - Renamed arguments to `sqlInterpolate()` and `sqlParseVariables()` to be more consistent with the rest of the interface, and added `.dots` argument to `sqlParseVariables`. DBI drivers are now expected to implement `sqlParseVariables(conn, sql, ..., .dots)` and `sqlInterpolate(conn, sql, ...)` (#147). - Interface enhancements - Removed `valueClass = "logical"` for those generics where the return value is meaningless, to allow backends to return invisibly (#135). - Avoiding using braces in the definitions of generics if possible, so that standard generics can be detected (#146). - Added default implementation for `dbReadTable()`. - All standard generics are required to have an ellipsis (with test), for future extensibility. - Improved default implementation of `dbQuoteString()` and `dbQuoteIdentifier()` (#77). - Removed `tryCatch()` call in `dbGetQuery()` (#113). - Documentation improvements - Finalized first draft of DBI specification, now in a vignette. - Most methods now draw documentation from `DBItest`, only those where the behavior is not finally decided don't do this yet yet. - Removed `max.connections` requirement from documentation (#56). - Improved `dbBind()` documentation and example (#136). - Change `omegahat.org` URL to `omegahat.net`, the particular document still doesn't exist below the new domain. - Internal - Use roxygen2 inheritance to copy DBI specification to this package. - Use `tic` package for building documentation. - Use markdown in documentation. # DBI 0.5-1 (2016-09-09) - Documentation and example updates. # DBI 0.5 (2016-08-11, CRAN release) - Interface changes - `dbDataType()` maps `character` values to `"TEXT"` by default (#102). - The default implementation of `dbQuoteString()` doesn't call `encodeString()` anymore: Neither SQLite nor Postgres understand e.g. `\n` in a string literal, and all of SQLite, Postgres, and MySQL accept an embedded newline (#121). - Interface enhancements - New `dbSendStatement()` generic, forwards to `dbSendQuery()` by default (#20, #132). - New `dbExecute()`, calls `dbSendStatement()` by default (#109, @bborgesr). - New `dbWithTransaction()` that calls `dbBegin()` and `dbCommit()`, and `dbRollback()` on failure (#110, @bborgesr). - New `dbBreak()` function which allows aborting from within `dbWithTransaction()` (#115, #133). - Export `dbFetch()` and `dbQuoteString()` methods. - Documentation improvements: - One example per function (except functions scheduled for deprecation) (#67). - Consistent layout and identifier naming. - Better documentation of generics by adding links to the class and related generics in the "See also" section under "Other DBI... generics" (#130). S4 documentation is directed to a hidden page to unclutter documentation index (#59). - Fix two minor vignette typos (#124, @mdsumner). - Add package documentation. - Remove misleading parts in `dbConnect()` documentation (#118). - Remove misleading link in `dbDataType()` documentation. - Remove full stop from documentation titles. - New help topic "DBIspec" that contains the full DBI specification (currently work in progress) (#129). - HTML documentation generated by `staticdocs` is now uploaded to http://rstats-db.github.io/DBI for each build of the "production" branch (#131). - Further minor changes and fixes. - Internal - Use `contains` argument instead of `representation()` to denote base classes (#93). - Remove redundant declaration of transaction methods (#110, @bborgesr). # DBI 0.4-1 (2016-05-07, CRAN release) - The default `show()` implementations silently ignore all errors. Some DBI drivers (e.g., RPostgreSQL) might fail to implement `dbIsValid()` or the other methods used. # DBI 0.4 (2016-04-30) * New package maintainer: Kirill Müller. * `dbGetInfo()` gains a default method that extracts the information from `dbGetStatement()`, `dbGetRowsAffected()`, `dbHasCompleted()`, and `dbGetRowCount()`. This means that most drivers should no longer need to implement `dbGetInfo()` (which may be deprecated anyway at some point) (#55). * `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. * New generic `dbBind()` for binding values to a parameterised query. * DBI gains a number of SQL generation functions. These make it easier to write backends by implementing common operations that are slightly tricky to do absolutely correctly. * `sqlCreateTable()` and `sqlAppendTable()` create tables from a data frame and insert rows into an existing table. These will power most implementations of `dbWriteTable()`. `sqlAppendTable()` is useful for databases that support parameterised queries. * `sqlRownamesToColumn()` and `sqlColumnToRownames()` provide a standard way of translating row names to and from the database. * `sqlInterpolate()` and `sqlParseVariables()` allows databases without native parameterised queries to use parameterised queries to avoid SQL injection attacks. * `sqlData()` is a new generic that converts a data frame into a data frame suitable for sending to the database. This is used to (e.g.) ensure all character vectors are encoded as UTF-8, or to convert R varible types (like factor) to types supported by the database. * The `sqlParseVariablesImpl()` is now implemented purely in R, with full test coverage (#83, @hannesmuehleisen). * `dbiCheckCompliance()` has been removed, the functionality is now available in the `DBItest` package (#80). * Added default `show()` methods for driver, connection and results. * New concrete `ANSIConnection` class and `ANSI()` function to generate a dummy ANSI compliant connection useful for testing. * Default `dbQuoteString()` and `dbQuoteIdentifer()` methods now use `encodeString()` so that special characters like `\n` are correctly escaped. `dbQuoteString()` converts `NA` to (unquoted) NULL. * The initial DBI proposal and DBI version 1 specification are now included as a vignette. These are there mostly for historical interest. * The new `DBItest` package is described in the vignette. * Deprecated `print.list.pairs()`. * Removed unused `dbi_dep()`. # Version 0.3.1 * Actually export `dbIsValid()` :/ * `dbGetQuery()` uses `dbFetch()` in the default implementation. # Version 0.3.0 ## New and enhanced generics * `dbIsValid()` returns a logical value describing whether a connection or result set (or other object) is still valid. (#12). * `dbQuoteString()` and `dbQuoteIdentifier()` to implement database specific quoting mechanisms. * `dbFetch()` added as alias to `fetch()` to provide consistent name. Implementers should define methods for both `fetch()` and `dbFetch()` until `fetch()` is deprecated in 2015. For now, the default method for `dbFetch()` calls `fetch()`. * `dbBegin()` begins a transaction (#17). If not supported, DB specific methods should throw an error (as should `dbCommit()` and `dbRollback()`). ## New default methods * `dbGetStatement()`, `dbGetRowsAffected()`, `dbHasCompleted()`, and `dbGetRowCount()` gain default methods that extract the appropriate elements from `dbGetInfo()`. This means that most drivers should no longer need to implement these methods (#13). * `dbGetQuery()` gains a default method for `DBIConnection` which uses `dbSendQuery()`, `fetch()` and `dbClearResult()`. ## Deprecated features * The following functions are soft-deprecated. They are going away, and developers who use the DBI should begin preparing. The formal deprecation process will begin in July 2015, where these function will emit warnings on use. * `fetch()` is replaced by `dbFetch()`. * `make.db.names()`, `isSQLKeyword()` and `SQLKeywords()`: a black list based approach is fundamentally flawed; instead quote strings and identifiers with `dbQuoteIdentifier()` and `dbQuoteString()`. * `dbGetDBIVersion()` is deprecated since it's now just a thin wrapper around `packageVersion("DBI")`. * `dbSetDataMappings()` (#9) and `dbCallProc()` (#7) are deprecated as no implementations were ever provided. ## Other improvements * `dbiCheckCompliance()` makes it easier for implementors to check that their package is in compliance with the DBI specification. * All examples now use the RSQLite package so that you can easily try out the code samples (#4). * `dbDriver()` gains a more effective search mechanism that doesn't rely on packages being loaded (#1). * DBI has been converted to use roxygen2 for documentation, and now most functions have their own documentation files. I would love your feedback on how we could make the documentation better! # Version 0.2-7 * Trivial changes (updated package fields, daj) # Version 0.2-6 * Removed deprecated \synopsis in some Rd files (thanks to Prof. Ripley) # Version 0.2-5 * Code cleanups contributed by Matthias Burger: avoid partial argument name matching and use TRUE/FALSE, not T/F. * Change behavior of make.db.names.default to quote SQL keywords if allow.keywords is FALSE. Previously, SQL keywords would be name mangled with underscores and a digit. Now they are quoted using '"'. # Version 0.2-4 * Changed license from GPL to LPGL * Fixed a trivial typo in documentation # Version 0.1-10 * Fixed documentation typos. # Version 0.1-9 * Trivial changes. # Version 0.1-8 * A trivial change due to package.description() being deprecated in 1.9.0. # Version 0.1-7 * Had to do a substantial re-formatting of the documentation due to incompatibilities introduced in 1.8.0 S4 method documentation. The contents were not changed (modulo fixing a few typos). Thanks to Kurt Hornik and John Chambers for their help. # Version 0.1-6 * Trivial documentation changes (for R CMD check's sake) # Version 0.1-5 * Removed duplicated setGeneric("dbSetDataMappings") # Version 0.1-4 * Removed the "valueClass" from some generic functions, namely, dbListConnections, dbListResults, dbGetException, dbGetQuery, and dbGetInfo. The reason is that methods for these generics could potentially return different classes of objects (e.g., the call dbGetInfo(res) could return a list of name-value pairs, while dbGetInfo(res, "statement") could be a character vector). * Added 00Index to inst/doc * Added dbGetDBIVersion() (simple wrapper to package.description). # Version 0.1-3 * ??? Minor changes? # Version 0.1-2 * An implementation based on version 4 classes and methods. * Incorporated (mostly Tim Keitt's) comments. DBI/R/0000755000176200001440000000000013070015125011043 5ustar liggesusersDBI/R/DBResult.R0000644000176200001440000002577713057746011012706 0ustar liggesusers#' DBIResult class #' #' This virtual class describes the result and state of execution of #' a DBMS statement (any statement, query or non-query). The result set #' keeps track of whether the statement produces output how many rows were #' affected by the operation, how many rows have been fetched (if statement is #' a query), whether there are more rows to fetch, etc. #' #' @section Implementation notes: #' Individual drivers are free to allow single or multiple #' active results per connection. #' #' The default show method displays a summary of the query using other #' DBI generics. #' #' @name DBIResult-class #' @docType class #' @family DBI classes #' @family DBIResult generics #' @export #' @include DBObject.R setClass("DBIResult", contains = c("DBIObject", "VIRTUAL")) #' @rdname hidden_aliases #' @param object Object to display #' @export setMethod("show", "DBIResult", function(object) { # to protect drivers that fail to implement the required methods (e.g., # RPostgreSQL) tryCatch( show_result(object), error = function(e) NULL) invisible(NULL) }) show_result <- function(object) { cat("<", is(object)[1], ">\n", sep = "") if(!dbIsValid(object)){ cat("EXPIRED\n") } else { cat(" SQL ", dbGetStatement(object), "\n", sep = "") done <- if (dbHasCompleted(object)) "complete" else "incomplete" cat(" ROWS Fetched: ", dbGetRowCount(object), " [", done, "]\n", sep = "") cat(" Changed: ", dbGetRowsAffected(object), "\n", sep = "") } } #' Fetch records from a previously executed query #' #' Fetch the next `n` elements (rows) from the result set and return them #' as a data.frame. #' #' `fetch()` is provided for compatibility with older DBI clients - for all #' new code you are strongly encouraged to use `dbFetch()`. The default #' implementation for `dbFetch()` calls `fetch()` so that it is compatible with #' existing code. Modern backends should implement for `dbFetch()` only. #' #' @inherit DBItest::spec_result_fetch return #' @inheritSection DBItest::spec_result_fetch Specification #' @inheritSection DBItest::spec_result_roundtrip Specification #' #' @param res An object inheriting from [DBIResult-class], created by #' [dbSendQuery()]. #' @param n maximum number of records to retrieve per fetch. Use `n = -1` #' or `n = Inf` #' to retrieve all pending records. Some implementations may recognize other #' special values. #' @param ... Other arguments passed on to methods. #' @seealso Close the result set with [dbClearResult()] as soon as you #' finish retrieving the records you want. #' @family DBIResult generics #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars) #' #' # Fetch all results #' rs <- dbSendQuery(con, "SELECT * FROM mtcars WHERE cyl = 4") #' dbFetch(rs) #' dbClearResult(rs) #' #' # Fetch in chunks #' rs <- dbSendQuery(con, "SELECT * FROM mtcars") #' while (!dbHasCompleted(rs)) { #' chunk <- dbFetch(rs, 10) #' print(nrow(chunk)) #' } #' #' dbClearResult(rs) #' dbDisconnect(con) #' @export setGeneric("dbFetch", def = function(res, n = -1, ...) standardGeneric("dbFetch"), valueClass = "data.frame" ) #' @rdname hidden_aliases #' @export setMethod("dbFetch", "DBIResult", function(res, n = -1, ...) { fetch(res, n = n, ...) }) #' @rdname dbFetch #' @export setGeneric("fetch", def = function(res, n = -1, ...) standardGeneric("fetch"), valueClass = "data.frame" ) #' Clear a result set #' #' Frees all resources (local and remote) associated with a result set. In some #' cases (e.g., very large result sets) this can be a critical step to avoid #' exhausting resources (memory, file descriptors, etc.) #' #' @inherit DBItest::spec_result_clear_result return #' @inheritSection DBItest::spec_result_clear_result Specification #' #' @param res An object inheriting from [DBIResult-class]. #' @param ... Other arguments passed on to methods. #' @family DBIResult generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' rs <- dbSendQuery(con, "SELECT 1") #' print(dbFetch(rs)) #' #' dbClearResult(rs) #' dbDisconnect(con) setGeneric("dbClearResult", def = function(res, ...) standardGeneric("dbClearResult") ) #' Information about result types #' #' Produces a data.frame that describes the output of a query. The data.frame #' should have as many rows as there are output fields in the result set, and #' each column in the data.frame should describe an aspect of the result set #' field (field name, type, etc.) #' #' @inheritParams dbClearResult #' @return A data.frame with one row per output field in `res`. Methods #' MUST include `name`, `field.type` (the SQL type), #' and `data.type` (the R data type) columns, and MAY contain other #' database specific information like scale and precision or whether the #' field can store `NULL`s. #' @family DBIResult generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' rs <- dbSendQuery(con, "SELECT 1 AS a, 2 AS b") #' dbColumnInfo(rs) #' dbFetch(rs) #' #' dbClearResult(rs) #' dbDisconnect(con) setGeneric("dbColumnInfo", def = function(res, ...) standardGeneric("dbColumnInfo"), valueClass = "data.frame" ) #' Get the statement associated with a result set #' #' Returns the statement that was passed to [dbSendQuery()] #' or [dbSendStatement()]. #' #' @inherit DBItest::spec_meta_get_statement return #' #' @inheritParams dbClearResult #' @family DBIResult generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars) #' rs <- dbSendQuery(con, "SELECT * FROM mtcars") #' dbGetStatement(rs) #' #' dbClearResult(rs) #' dbDisconnect(con) setGeneric("dbGetStatement", def = function(res, ...) standardGeneric("dbGetStatement"), valueClass = "character" ) #' Completion status #' #' This method returns if the operation has completed. #' A `SELECT` query is completed if all rows have been fetched. #' A data manipulation statement is always completed. #' #' @inherit DBItest::spec_meta_has_completed return #' @inheritSection DBItest::spec_meta_has_completed Specification #' #' @inheritParams dbClearResult #' @family DBIResult generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars) #' rs <- dbSendQuery(con, "SELECT * FROM mtcars") #' #' dbHasCompleted(rs) #' ret1 <- dbFetch(rs, 10) #' dbHasCompleted(rs) #' ret2 <- dbFetch(rs) #' dbHasCompleted(rs) #' #' dbClearResult(rs) #' dbDisconnect(con) setGeneric("dbHasCompleted", def = function(res, ...) standardGeneric("dbHasCompleted"), valueClass = "logical" ) #' The number of rows affected #' #' This method returns the number of rows that were added, deleted, or updated #' by a data manipulation statement. #' #' @inherit DBItest::spec_meta_get_rows_affected return #' #' @inheritParams dbClearResult #' @family DBIResult generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars) #' rs <- dbSendStatement(con, "DELETE FROM mtcars") #' dbGetRowsAffected(rs) #' nrow(mtcars) #' #' dbClearResult(rs) #' dbDisconnect(con) setGeneric("dbGetRowsAffected", def = function(res, ...) standardGeneric("dbGetRowsAffected"), valueClass = "numeric" ) #' The number of rows fetched so far #' #' Returns the total number of rows actually fetched with calls to [dbFetch()] #' for this result set. #' #' @inherit DBItest::spec_meta_get_row_count return #' #' @inheritParams dbClearResult #' @family DBIResult generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars) #' rs <- dbSendQuery(con, "SELECT * FROM mtcars") #' #' dbGetRowCount(rs) #' ret1 <- dbFetch(rs, 10) #' dbGetRowCount(rs) #' ret2 <- dbFetch(rs) #' dbGetRowCount(rs) #' nrow(ret1) + nrow(ret2) #' #' dbClearResult(rs) #' dbDisconnect(con) setGeneric("dbGetRowCount", def = function(res, ...) standardGeneric("dbGetRowCount"), valueClass = "numeric" ) #' @name dbGetInfo #' @section Implementation notes: #' The default implementation for `DBIResult objects` #' constructs such a list from the return values of the corresponding methods, #' [dbGetStatement()], [dbGetRowCount()], #' [dbGetRowsAffected()], and [dbHasCompleted()]. NULL #' @rdname hidden_aliases setMethod("dbGetInfo", "DBIResult", function(dbObj, ...) { list( statement = dbGetStatement(dbObj), row.count = dbGetRowCount(dbObj), rows.affected = dbGetRowsAffected(dbObj), has.completed = dbHasCompleted(dbObj) ) }) #' Bind values to a parameterized/prepared statement #' #' For parametrized or prepared statements, #' the [dbSendQuery()] and [dbSendStatement()] functions can be called with #' statements that contain placeholders for values. The `dbBind()` function #' binds these placeholders #' to actual values, and is intended to be called on the result set #' before calling [dbFetch()] or [dbGetRowsAffected()]. #' #' \pkg{DBI} supports parametrized (or prepared) queries and statements #' via the `dbBind()` generic. #' Parametrized queries are different from normal queries #' in that they allow an arbitrary number of placeholders, #' which are later substituted by actual values. #' Parametrized queries (and statements) serve two purposes: #' #' - The same query can be executed more than once with different values. #' The DBMS may cache intermediate information for the query, #' such as the execution plan, #' and execute it faster. #' - Separation of query syntax and parameters protects against SQL injection. #' #' The placeholder format is currently not specified by \pkg{DBI}; #' in the future, a uniform placeholder syntax may be supported. #' Consult the backend documentation for the supported formats. #' For automated testing, backend authors specify the placeholder syntax with #' the `placeholder_pattern` tweak. #' Known examples are: #' #' - `?` (positional matching in order of appearance) in \pkg{RMySQL} and \pkg{RSQLite} #' - `$1` (positional matching by index) in \pkg{RPostgres} and \pkg{RSQLite} #' - `:name` and `$name` (named matching) in \pkg{RSQLite} #' #' @inherit DBItest::spec_meta_bind return #' @inheritSection DBItest::spec_meta_bind Specification #' #' @inheritParams dbClearResult #' @param params A list of bindings, named or unnamed. #' @family DBIResult generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "iris", iris) #' #' # Using the same query for different values #' iris_result <- dbSendQuery(con, "SELECT * FROM iris WHERE [Petal.Width] > ?") #' dbBind(iris_result, list(2.3)) #' dbFetch(iris_result) #' dbBind(iris_result, list(3)) #' dbFetch(iris_result) #' dbClearResult(iris_result) #' #' # Executing the same statement with different values at once #' iris_result <- dbSendStatement(con, "DELETE FROM iris WHERE [Species] = $species") #' dbBind(iris_result, list(species = c("setosa", "versicolor", "unknown"))) #' dbGetRowsAffected(iris_result) #' dbClearResult(iris_result) #' #' nrow(dbReadTable(con, "iris")) #' #' dbDisconnect(con) setGeneric( "dbBind", function(res, params, ...) standardGeneric("dbBind") ) DBI/R/interpolate.R0000644000176200001440000001634613070015125013526 0ustar liggesusers#' Safely interpolate values into an SQL string #' #' @section Backend authors: #' If you are implementing an SQL backend with non-ANSI quoting rules, you'll #' need to implement a method for [sqlParseVariables()]. Failure to #' do so does not expose you to SQL injection attacks, but will (rarely) result #' in errors matching supplied and interpolated variables. #' #' @param conn A database connection. #' @param sql A SQL string containing variables to interpolate. #' Variables must start with a question mark and can be any valid R #' identifier, i.e. it must start with a letter or `.`, and be followed #' by a letter, digit, `.` or `_`. #' @param ...,.dots Named values (for `...`) or a named list (for `.dots`) #' to interpolate into a string. All strings #' will be first escaped with [dbQuoteString()] prior #' to interpolation to protect against SQL injection attacks. #' @export #' @examples #' sql <- "SELECT * FROM X WHERE name = ?name" #' sqlInterpolate(ANSI(), sql, name = "Hadley") #' #' # This is safe because the single quote has been double escaped #' sqlInterpolate(ANSI(), sql, name = "H'); DROP TABLE--;") setGeneric( "sqlInterpolate", function(conn, sql, ..., .dots = list()) standardGeneric("sqlInterpolate") ) #' @rdname hidden_aliases #' @export setMethod("sqlInterpolate", "DBIConnection", function(conn, sql, ..., .dots = list()) { pos <- sqlParseVariables(conn, sql) if (length(pos$start) == 0) return(SQL(sql)) vars <- substring(sql, pos$start + 1, pos$end) values <- c(list(...), .dots) if (!setequal(vars, names(values))) { stop("Supplied vars don't match vars to interpolate", call. = FALSE) } values <- values[vars] safe_values <- vapply(values, function(x) { if (is.character(x)) { dbQuoteString(conn, x) } else { as.character(x) } }, character(1)) for (i in rev(seq_along(vars))) { sql <- paste0( substring(sql, 0, pos$start[i] - 1), safe_values[i], substring(sql, pos$end[i] + 1, nchar(sql)) ) } SQL(sql) }) #' Parse interpolated variables from SQL. #' #' If you're implementing a backend that uses non-ANSI quoting or commenting #' rules, you'll need to implement a method for `sqlParseVariables` that #' calls `sqlParseVariablesImpl` with the appropriate quote and #' comment specifications. #' #' #' @param start,end Start and end characters for quotes and comments #' @param endRequired Is the ending character of a comment required? #' @param doubleEscape Can quoting characters be escaped by doubling them? #' Defaults to `TRUE`. #' @param escape What character can be used to escape quoting characters? #' Defaults to `""`, i.e. nothing. #' @keywords internal #' @export #' @examples #' # Use [] for quoting and no comments #' sqlParseVariablesImpl("[?a]", #' list(sqlQuoteSpec("[", "]", "\\", FALSE)), #' list() #' ) #' #' # Standard quotes, use # for commenting #' sqlParseVariablesImpl("# ?a\n?b", #' list(sqlQuoteSpec("'", "'"), sqlQuoteSpec('"', '"')), #' list(sqlCommentSpec("#", "\n", FALSE)) #' ) setGeneric( "sqlParseVariables", function(conn, sql, ...) standardGeneric("sqlParseVariables") ) #' @rdname hidden_aliases #' @export setMethod("sqlParseVariables", "DBIConnection", function(conn, sql, ...) { sqlParseVariablesImpl(sql, list( sqlQuoteSpec('"', '"'), sqlQuoteSpec("'", "'") ), list( sqlCommentSpec("/*", "*/", TRUE), sqlCommentSpec("--", "\n", FALSE) ) ) }) #' @export #' @rdname sqlParseVariables sqlCommentSpec <- function(start, end, endRequired) { list(start, end, endRequired) } #' @export #' @rdname sqlParseVariables sqlQuoteSpec <- function(start, end, escape = "", doubleEscape = TRUE) { list(start, end, escape, doubleEscape) } #' @export #' @rdname sqlParseVariables #' @param sql SQL to parse (a character string) #' @param quotes A list of `QuoteSpec` calls defining the quoting #' specification. #' @param comments A list of `CommentSpec` calls defining the commenting #' specification. sqlParseVariablesImpl <- function(sql, quotes, comments) { sql_arr <- c(strsplit(as.character(sql), "", fixed = TRUE)[[1]], " ") # characters valid in variable names var_chars <- c(LETTERS, letters, 0:9, "_") # return values var_pos_start <- integer() var_pos_end <- integer() # internal helper variables quote_spec_offset <- 0L comment_spec_offset <- 0L sql_variable_start <- 0L # prepare comments & quotes for quicker comparisions for(c in seq_along(comments)) { comments[[c]][[1]] <- strsplit(comments[[c]][[1]], "", fixed = TRUE)[[1]] comments[[c]][[2]] <- strsplit(comments[[c]][[2]], "", fixed = TRUE)[[1]] } for(q in seq_along(quotes)) { quotes[[q]][[5]] <- nchar(quotes[[q]][[3]]) > 0L } state <- 'default' i <- 0 while(i < length(sql_arr)) { i <- i + 1 switch(state, default = { # variable? if (sql_arr[[i]] == "?") { sql_variable_start <- i state <- 'variable' next } # starting quoted area? for(q in seq_along(quotes)) { if (identical(sql_arr[[i]], quotes[[q]][[1]])) { quote_spec_offset <- q state <- 'quote' break } } # we can abort here if the state has changed if (state != 'default') next # starting comment? for(c in seq_along(comments)) { comment_start_arr <- comments[[c]][[1]] comment_start_length <- length(comment_start_arr) if (identical(sql_arr[i:(i + comment_start_length - 1)], comment_start_arr)) { comment_spec_offset <- c i <- i + comment_start_length state <- 'comment' break } } }, variable = { if (!(sql_arr[[i]] %in% var_chars)) { # make sure variable has at least one character after the '?' if (i - sql_variable_start < 2) { stop("Length 0 variable") } # append current variable offsets to return vectors var_pos_start <- c(var_pos_start, sql_variable_start) var_pos_end <- c(var_pos_end, i - 1) # we have already read too much, go back i <- i - 1 state <- 'default' } }, quote = { # if we see backslash-like escapes, ignore next character if (quotes[[quote_spec_offset]][[5]] && identical(sql_arr[[i]], quotes[[quote_spec_offset]][[3]])) { i <- i + 1 next } # end quoted area? if (identical(sql_arr[[i]], quotes[[quote_spec_offset]][[2]])) { quote_spec_offset <- 0L state <- 'default' } }, comment = { # end commented area? comment_end_arr <- comments[[comment_spec_offset]][[2]] comment_end_length <- length(comment_end_arr) if (identical(sql_arr[i:(i + comment_end_length - 1)], comment_end_arr)) { i <- i + comment_end_length comment_spec_offset <- 0L state <- 'default' } } ) # } # if (quote_spec_offset > 0L) { stop("Unterminated literal") } if (comment_spec_offset > 0L && comments[[comment_spec_offset]][[3]]) { stop("Unterminated comment") } list(start = as.integer(var_pos_start), end = as.integer(var_pos_end)) } DBI/R/data-types.R0000644000176200001440000000232413055622377013262 0ustar liggesuserssetGeneric("dbiDataType", function(x, ...) standardGeneric("dbiDataType")) data_frame_data_type <- function(x) { vapply(x, dbiDataType, FUN.VALUE = character(1), USE.NAMES = TRUE) } varchar_data_type <- function(x) { "TEXT" } list_data_type <- function(x) { check_raw_list(x) "BLOB" } check_raw_list <- function(x) { is_raw <- vapply(x, is.raw, logical(1)) if (!all(is_raw)) { stop("Only lists of raw vectors are currently supported", call. = FALSE) } } as_is_data_type <- function(x) { dbiDataType(unclass(x)) } setOldClass("difftime") setOldClass("AsIs") setMethod("dbiDataType", "data.frame", data_frame_data_type) setMethod("dbiDataType", "integer", function(x) "INT") setMethod("dbiDataType", "numeric", function(x) "DOUBLE") setMethod("dbiDataType", "logical", function(x) "SMALLINT") setMethod("dbiDataType", "Date", function(x) "DATE") setMethod("dbiDataType", "difftime", function(x) "TIME") setMethod("dbiDataType", "POSIXct", function(x) "TIMESTAMP") setMethod("dbiDataType", "character", varchar_data_type) setMethod("dbiDataType", "factor", varchar_data_type) setMethod("dbiDataType", "list", list_data_type) setMethod("dbiDataType", "AsIs", as_is_data_type) DBI/R/quote.R0000644000176200001440000001235213055626140012336 0ustar liggesusers#' @include DBConnection.R NULL #' SQL quoting #' #' This set of classes and generics make it possible to flexibly deal with SQL #' escaping needs. By default, any user supplied input to a query should be #' escaped using either [dbQuoteIdentifier()] or [dbQuoteString()] #' depending on whether it refers to a table or variable name, or is a literal #' string. #' These functions may return an object of the `SQL` class, #' which tells DBI functions that a character string does not need to be escaped #' anymore, to prevent double escaping. #' The `SQL` class has associated the `SQL()` constructor function. #' #' @section Implementation notes: #' #' DBI provides default generics for SQL-92 compatible quoting. If the database #' uses a different convention, you will need to provide your own methods. #' Note that because of the way that S4 dispatch finds methods and because #' SQL inherits from character, if you implement (e.g.) a method for #' `dbQuoteString(MyConnection, character)`, you will also need to #' implement `dbQuoteString(MyConnection, SQL)` - this should simply #' return `x` unchanged. #' #' @param x A character vector to label as being escaped SQL. #' @param ... Other arguments passed on to methods. Not otherwise used. #' @return An object of class `SQL`. #' @export #' @examples #' dbQuoteIdentifier(ANSI(), "SELECT") #' dbQuoteString(ANSI(), "SELECT") #' #' # SQL vectors are always passed through as is #' var_name <- SQL("SELECT") #' var_name #' #' dbQuoteIdentifier(ANSI(), var_name) #' dbQuoteString(ANSI(), var_name) #' #' # This mechanism is used to prevent double escaping #' dbQuoteString(ANSI(), dbQuoteString(ANSI(), "SELECT")) SQL <- function(x) new("SQL", x) #' @rdname SQL #' @export #' @aliases #' SQL-class setClass("SQL", contains = "character") #' @rdname hidden_aliases #' @export setMethod("show", "SQL", function(object) { cat(paste0(" ", object@.Data, collapse = "\n"), "\n", sep = "") }) #' Quote identifiers #' #' Call this method to generate a string that is suitable for #' use in a query as a column name, to make sure that you #' generate valid SQL and avoid SQL injection. #' #' @param conn A subclass of [DBIConnection-class], representing #' an active connection to an DBMS. #' @param x A character vector to quote as identifier. #' @param ... Other arguments passed on to methods. #' #' @inherit DBItest::spec_sql_quote_identifier return #' @inheritSection DBItest::spec_sql_quote_identifier Specification #' #' @family DBIResult generics #' @export #' @examples #' # Quoting ensures that arbitrary input is safe for use in a query #' name <- "Robert'); DROP TABLE Students;--" #' dbQuoteIdentifier(ANSI(), name) #' #' # SQL vectors are always passed through as is #' var_name <- SQL("select") #' var_name #' #' dbQuoteIdentifier(ANSI(), var_name) #' #' # This mechanism is used to prevent double escaping #' dbQuoteIdentifier(ANSI(), dbQuoteIdentifier(ANSI(), name)) setGeneric( "dbQuoteIdentifier", function(conn, x, ...) standardGeneric("dbQuoteIdentifier") ) #' @rdname hidden_aliases #' @export setMethod("dbQuoteIdentifier", c("DBIConnection", "character"), function(conn, x, ...) { if (any(is.na(x))) { stop("Cannot pass NA to dbQuoteIdentifier()", call. = FALSE) } x <- gsub('"', '""', x, fixed = TRUE) if (length(x) == 0L) { SQL(character()) } else { # Not calling encodeString() here to keep things simple SQL(paste('"', x, '"', sep = "")) } } ) #' @rdname hidden_aliases #' @export setMethod("dbQuoteIdentifier", c("DBIConnection", "SQL"), function(conn, x, ...) { x } ) #' Quote literal strings #' #' Call this method to generate a string that is suitable for #' use in a query as a string literal, to make sure that you #' generate valid SQL and avoid SQL injection. #' #' @param conn A subclass of [DBIConnection-class], representing #' an active connection to an DBMS. #' @param x A character vector to quote as string. #' @param ... Other arguments passed on to methods. #' #' @inherit DBItest::spec_sql_quote_string return #' @inheritSection DBItest::spec_sql_quote_string Specification #' #' @family DBIResult generics #' @export #' @examples #' # Quoting ensures that arbitrary input is safe for use in a query #' name <- "Robert'); DROP TABLE Students;--" #' dbQuoteString(ANSI(), name) #' #' # NAs become NULL #' dbQuoteString(ANSI(), c("x", NA)) #' #' # SQL vectors are always passed through as is #' var_name <- SQL("select") #' var_name #' dbQuoteString(ANSI(), var_name) #' #' # This mechanism is used to prevent double escaping #' dbQuoteString(ANSI(), dbQuoteString(ANSI(), name)) setGeneric( "dbQuoteString", function(conn, x, ...) standardGeneric("dbQuoteString") ) #' @rdname hidden_aliases #' @export setMethod("dbQuoteString", c("DBIConnection", "character"), function(conn, x, ...) { x <- gsub("'", "''", x, fixed = TRUE) if (length(x) == 0L) { SQL(character()) } else { # Not calling encodeString() here, see also http://stackoverflow.com/a/549244/946850 # and especially the comment by Álvaro González str <- paste("'", x, "'", sep = "") str[is.na(x)] <- "NULL" SQL(str) } } ) #' @rdname hidden_aliases #' @export setMethod("dbQuoteString", c("DBIConnection", "SQL"), function(conn, x, ...) { x } ) DBI/R/DBDriver.R0000644000176200001440000001777413060005002012637 0ustar liggesusers#' DBIDriver class #' #' Base class for all DBMS drivers (e.g., RSQLite, MySQL, PostgreSQL). #' The virtual class `DBIDriver` defines the operations for creating #' connections and defining data type mappings. Actual driver classes, for #' instance `RPgSQL`, `RMySQL`, etc. implement these operations in a #' DBMS-specific manner. #' #' @docType class #' @name DBIDriver-class #' @family DBI classes #' @family DBIDriver generics #' @export #' @include DBObject.R setClass("DBIDriver", contains = c("DBIObject", "VIRTUAL")) #' Load and unload database drivers #' #' @description #' These methods are deprecated, please consult the documentation of the #' individual backends for the construction of driver instances. #' #' `dbDriver()` is a helper method used to create an new driver object #' given the name of a database or the corresponding R package. It works #' through convention: all DBI-extending packages should provide an exported #' object with the same name as the package. `dbDriver()` just looks for #' this object in the right places: if you know what database you are connecting #' to, you should call the function directly. #' #' @details #' The client part of the database communication is #' initialized (typically dynamically loading C code, etc.) but note that #' connecting to the database engine itself needs to be done through calls to #' `dbConnect`. #' #' @param drvName character name of the driver to instantiate. #' @param drv an object that inherits from `DBIDriver` as created by #' `dbDriver`. #' @param ... any other arguments are passed to the driver `drvName`. #' @return In the case of `dbDriver`, an driver object whose class extends #' `DBIDriver`. This object may be used to create connections to the #' actual DBMS engine. #' #' In the case of `dbUnloadDriver`, a logical indicating whether the #' operation succeeded or not. #' @import methods #' @family DBIDriver generics #' @examples #' # Create a RSQLite driver with a string #' d <- dbDriver("SQLite") #' d #' #' # But better, access the object directly #' RSQLite::SQLite() #' @export setGeneric("dbDriver", def = function(drvName, ...) standardGeneric("dbDriver"), valueClass = "DBIDriver") #' @rdname hidden_aliases setMethod("dbDriver", "character", definition = function(drvName, ...) { findDriver(drvName)(...) } ) #' @rdname hidden_aliases #' @param object Object to display #' @export setMethod("show", "DBIDriver", function(object) { tryCatch( # to protect drivers that fail to implement the required methods (e.g., # RPostgreSQL) show_driver(object), error = function(e) NULL) invisible(NULL) }) show_driver <- function(object) { cat("<", is(object)[1], ">\n", sep = "") } findDriver <- function(drvName) { # If it exists in the global environment, use that d <- get2(drvName, globalenv()) if (!is.null(d)) return(d) # Otherwise, see if the appropriately named package is available if (is_attached(drvName)) { d <- get2(drvName, asNamespace(drvName)) if (!is.null(d)) return(d) } pkgName <- paste0("R", drvName) # First, see if package with name R + drvName is available if (is_attached(pkgName)) { d <- get2(drvName, asNamespace(pkgName)) if (!is.null(d)) return(d) } # Can't find it: stop("Couldn't find driver ", drvName, ". Looked in:\n", "* global namespace\n", "* in package called ", drvName, "\n", "* in package called ", pkgName, call. = FALSE) } get2 <- function(x, env) { if (!exists(x, envir = env)) return(NULL) get(x, envir = env) } is_attached <- function(x) { x %in% loadedNamespaces() } #' @description #' `dbUnloadDriver()` is not implemented for modern backends. #' @rdname dbDriver #' @family DBIDriver generics #' @export setGeneric("dbUnloadDriver", def = function(drv, ...) standardGeneric("dbUnloadDriver") ) #' Create a connection to a DBMS #' #' Connect to a DBMS going through the appropriate authentication procedure. #' Some implementations may allow you to have multiple connections open, so you #' may invoke this function repeatedly assigning its output to different #' objects. #' The authentication mechanism is left unspecified, so check the #' documentation of individual drivers for details. #' #' @inherit DBItest::spec_driver_connect return #' @inheritSection DBItest::spec_driver_connect Specification #' #' @param drv an object that inherits from [DBIDriver-class], #' or an existing [DBIConnection-class] #' object (in order to clone an existing connection). #' @param ... authentication arguments needed by the DBMS instance; these #' typically include `user`, `password`, `host`, `port`, `dbname`, etc. #' For details see the appropriate `DBIDriver`. #' @seealso [dbDisconnect()] to disconnect from a database. #' @family DBIDriver generics #' @export #' @examples #' # SQLite only needs a path to the database. (Here, ":memory:" is a special #' # path that creates an in-memory database.) Other database drivers #' # will require more details (like user, password, host, port, etc.) #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' con #' #' dbListTables(con) #' #' dbDisconnect(con) setGeneric("dbConnect", def = function(drv, ...) standardGeneric("dbConnect"), valueClass = "DBIConnection" ) #' List currently open connections #' #' Drivers that implement only a single connections MUST return a list #' containing a single element. If no connection are open, methods MUST #' return an empty list. #' #' @param drv A object inheriting from [DBIDriver-class] #' @param ... Other arguments passed on to methods. #' @family DBIDriver generics #' @export #' @return a list setGeneric("dbListConnections", def = function(drv, ...) standardGeneric("dbListConnections") ) #' Determine the SQL data type of an object #' #' Returns an SQL string that describes the SQL data type to be used for an #' object. #' The default implementation of this generic determines the SQL type of an #' R object according to the SQL 92 specification, which may serve as a starting #' point for driver implementations. DBI also provides an implementation #' for data.frame which will return a character vector giving the type for each #' column in the dataframe. #' #' The data types supported by databases are different than the data types in R, #' but the mapping between the primitive types is straightforward: #' - Any of the many fixed and varying length character types are mapped to #' character vectors #' - Fixed-precision (non-IEEE) numbers are mapped into either numeric or #' integer vectors. #' #' Notice that many DBMS do not follow IEEE arithmetic, so there are potential #' problems with under/overflows and loss of precision. #' #' @inherit DBItest::spec_driver_data_type return #' @inheritSection DBItest::spec_driver_data_type Specification #' @inheritSection DBItest::spec_result_create_table_with_data_type Specification #' #' @inheritParams dbListConnections #' @param dbObj A object inheriting from [DBIDriver-class] #' or [DBIConnection-class] #' @param obj An R object whose SQL type we want to determine. #' @family DBIDriver generics #' @family DBIConnection generics #' @examples #' dbDataType(ANSI(), 1:5) #' dbDataType(ANSI(), 1) #' dbDataType(ANSI(), TRUE) #' dbDataType(ANSI(), Sys.Date()) #' dbDataType(ANSI(), Sys.time()) #' dbDataType(ANSI(), Sys.time() - as.POSIXct(Sys.Date())) #' dbDataType(ANSI(), c("x", "abc")) #' dbDataType(ANSI(), list(raw(10), raw(20))) #' dbDataType(ANSI(), I(3)) #' #' dbDataType(ANSI(), iris) #' #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbDataType(con, 1:5) #' dbDataType(con, 1) #' dbDataType(con, TRUE) #' dbDataType(con, Sys.Date()) #' dbDataType(con, Sys.time()) #' dbDataType(con, Sys.time() - as.POSIXct(Sys.Date())) #' dbDataType(con, c("x", "abc")) #' dbDataType(con, list(raw(10), raw(20))) #' dbDataType(con, I(3)) #' #' dbDataType(con, iris) #' #' dbDisconnect(con) #' @export setGeneric("dbDataType", def = function(dbObj, obj, ...) standardGeneric("dbDataType"), valueClass = "character" ) #' @rdname hidden_aliases #' @export setMethod("dbDataType", "DBIObject", function(dbObj, obj, ...) { dbiDataType(obj) }) DBI/R/data.R0000644000176200001440000000467713055626140012125 0ustar liggesusers#' Convert a data frame into form suitable for upload to an SQL database #' #' This is a generic method that coerces R objects into vectors suitable for #' upload to the database. The output will vary a little from method to #' method depending on whether the main upload device is through a single #' SQL string or multiple parameterized queries. #' This method is mostly useful for backend implementers. #' #' The default method: #' \itemize{ #' \item Converts factors to characters #' \item Quotes all strings #' \item Converts all columns to strings #' \item Replaces NA with NULL #' } #' #' @inheritParams sqlCreateTable #' @inheritParams rownames #' @param value A data frame #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' sqlData(con, head(iris)) #' sqlData(con, head(mtcars)) #' #' dbDisconnect(con) setGeneric( "sqlData", function(con, value, row.names = NA, ...) standardGeneric("sqlData") ) #' @rdname hidden_aliases #' @export setMethod("sqlData", "DBIConnection", function(con, value, row.names = NA, ...) { value <- sqlRownamesToColumn(value, row.names) # Convert factors to strings is_factor <- vapply(value, is.factor, logical(1)) value[is_factor] <- lapply(value[is_factor], as.character) # Quote all strings is_char <- vapply(value, is.character, logical(1)) value[is_char] <- lapply(value[is_char], function(x) { enc2utf8(dbQuoteString(con, x)) }) # Convert everything to character and turn NAs into NULL value[] <- lapply(value, as.character) value[is.na(value)] <- "NULL" value }) # Coercion rules --------------------------------------------------------------- coerce <- function(sqlvar, from, to) { list(from = from, to = to) } sqlDate <- function() { coerce( function(x) as.integer(x), function(x) { stopifnot(is.integer(x)) structure(x, class = "Date") } ) } sqlDateTime <- function() { coerce( function(x) as.numeric(x), function(x) { stopifnot(is.numeric(x)) structure(x, class = c("POSIXct", "POSIXt"), tzone = "UTC") } ) } sqlSerialize <- function() { coerce( function(x) { lapply(x, serialize, connection = NULL) }, function(x) { lapply(x, unserialize) } ) } sqlBoolean <- function() { coerce( function(x) as.integer(x), function(x) as.logical(x) ) } sqlFactor <- function(levels) { coerce( function(x) as.integer(x), function(x) factor(x, levels = levels) ) } DBI/R/rownames.R0000644000176200001440000000526413055626140013040 0ustar liggesusers#' Convert row names back and forth between columns #' #' These functions provide a reasonably automatic way of preserving the row #' names of data frame during back-and-forth translation to an SQL table. #' By default, row names will be converted to an explicit column #' called "row_names", and any query returning a column called "row_names" #' will have those automatically set as row names. #' These methods are mostly useful for backend implementers. #' #' @param df A data frame #' @param row.names Either `TRUE`, `FALSE`, `NA` or a string. #' #' If `TRUE`, always translate row names to a column called "row_names". #' If `FALSE`, never translate row names. If `NA`, translate #' rownames only if they're a character vector. #' #' A string is equivalent to `TRUE`, but allows you to override the #' default name. #' #' For backward compatibility, `NULL` is equivalent to `FALSE`. #' @name rownames #' @examples #' # If have row names #' sqlRownamesToColumn(head(mtcars)) #' sqlRownamesToColumn(head(mtcars), FALSE) #' sqlRownamesToColumn(head(mtcars), "ROWNAMES") #' #' # If don't have #' sqlRownamesToColumn(head(iris)) #' sqlRownamesToColumn(head(iris), TRUE) #' sqlRownamesToColumn(head(iris), "ROWNAMES") #' NULL #' @export #' @rdname rownames sqlRownamesToColumn <- function(df, row.names = NA) { name <- guessRowName(df, row.names) if (is.null(name)) { rownames(df) <- NULL return(df) } rn <- stats::setNames(list(row.names(df)), name) df <- c(rn, df) class(df) <- "data.frame" attr(df, "row.names") <- .set_row_names(length(rn[[1]])) df } #' @export #' @rdname rownames sqlColumnToRownames <- function(df, row.names = NA) { name <- guessColName(df, row.names) if (is.null(name)) return(df) if (!(name %in% names(df))) { stop("Column ", name, " not present in output", call. = FALSE) } row.names(df) <- df[[name]] df[[name]] <- NULL df } guessRowName <- function(df, row.names) { if (identical(row.names, TRUE)) { "row_names" } else if (identical(row.names, FALSE) || is.null(row.names)) { NULL } else if (identical(row.names, NA)) { is_char <- is.character(attr(df, "row.names")) if (is_char) { "row_names" } else { NULL } } else if (is.character(row.names)) { row.names[1] } else { stop("Unknown input") } } guessColName <- function(df, row.names) { if (identical(row.names, TRUE)) { "row_names" } else if (identical(row.names, FALSE) || is.null(row.names)) { NULL } else if (identical(row.names, NA)) { if ("row_names" %in% names(df)) { "row_names" } else { NULL } } else if (is.character(row.names)) { row.names[1] } else { stop("Unknown input") } } DBI/R/DBObject.R0000644000176200001440000000706313055626140012620 0ustar liggesusers#' DBIObject class #' #' Base class for all other DBI classes (e.g., drivers, connections). This #' is a virtual Class: No objects may be created from it. #' #' More generally, the DBI defines a very small set of classes and generics that #' allows users and applications access DBMS with a common interface. The #' virtual classes are `DBIDriver` that individual drivers extend, #' `DBIConnection` that represent instances of DBMS connections, and #' `DBIResult` that represent the result of a DBMS statement. These three #' classes extend the basic class of `DBIObject`, which serves as the root #' or parent of the class hierarchy. #' #' @section Implementation notes: #' An implementation MUST provide methods for the following generics: #' #' \itemize{ #' \item [dbGetInfo()]. #' } #' #' It MAY also provide methods for: #' #' \itemize{ #' \item [summary()]. Print a concise description of the #' object. The default method invokes `dbGetInfo(dbObj)` and prints #' the name-value pairs one per line. Individual implementations may #' tailor this appropriately. #' } #' #' @docType class #' @family DBI classes #' @examples #' drv <- RSQLite::SQLite() #' con <- dbConnect(drv) #' #' rs <- dbSendQuery(con, "SELECT 1") #' is(drv, "DBIObject") ## True #' is(con, "DBIObject") ## True #' is(rs, "DBIObject") #' #' dbClearResult(rs) #' dbDisconnect(con) #' @export #' @name DBIObject-class setClass("DBIObject", "VIRTUAL") #' Get DBMS metadata #' #' @section Implementation notes: #' For `DBIDriver` subclasses, this should include the version of the #' package (`driver.version`) and the version of the underlying client #' library (`client.version`). #' #' For `DBIConnection` objects this should report the version of #' the DBMS engine (`db.version`), database name (`dbname`), #' username, (`username`), host (`host`), port (`port`), etc. #' It MAY also include any other arguments related to the connection #' (e.g., thread id, socket or TCP connection type). It MUST NOT include the #' password. #' #' For `DBIResult` objects, this should include the statement #' being executed (`statement`), how many rows have been fetched so far #' (in the case of queries, `row.count`), how many rows were affected #' (deleted, inserted, changed, #' (`rows.affected`), and if the query is complete (`has.completed`). #' #' @param dbObj An object inheriting from [DBIObject-class], #' i.e. [DBIDriver-class], [DBIConnection-class], #' or a [DBIResult-class] #' @param ... Other arguments to methods. #' @family DBIDriver generics #' @family DBIConnection generics #' @family DBIResult generics #' @return a named list #' @export setGeneric("dbGetInfo", def = function(dbObj, ...) standardGeneric("dbGetInfo") ) #' Is this DBMS object still valid? #' #' This generic tests whether a database object is still valid (i.e. it hasn't #' been disconnected or cleared). #' #' @inherit DBItest::spec_meta_is_valid return #' #' @inheritParams dbGetInfo #' @family DBIDriver generics #' @family DBIConnection generics #' @family DBIResult generics #' @export #' @examples #' dbIsValid(RSQLite::SQLite()) #' #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' dbIsValid(con) #' #' rs <- dbSendQuery(con, "SELECT 1") #' dbIsValid(rs) #' #' dbClearResult(rs) #' dbIsValid(rs) #' #' dbDisconnect(con) #' dbIsValid(con) setGeneric("dbIsValid", def = function(dbObj, ...) standardGeneric("dbIsValid"), valueClass = "logical") setGeneric("summary") setMethod("summary", "DBIObject", function(object, ...) { info <- dbGetInfo(dbObj = object, ...) cat(class(object), "\n") print_list_pairs(info) invisible(info) }) DBI/R/deprecated.R0000644000176200001440000002252413055622377013313 0ustar liggesusers#' Make R identifiers into legal SQL identifiers #' #' These methods are DEPRECATED. Please use [dbQuoteIdentifier()] #' (or possibly [dbQuoteString()]) instead. #' #' The algorithm in `make.db.names` first invokes `make.names` and #' then replaces each occurrence of a dot `.` by an underscore `_`. If #' `allow.keywords` is `FALSE` and identifiers collide with SQL #' keywords, a small integer is appended to the identifier in the form of #' `"_n"`. #' #' The set of SQL keywords is stored in the character vector #' `.SQL92Keywords` and reflects the SQL ANSI/ISO standard as documented #' in "X/Open SQL and RDA", 1994, ISBN 1-872630-68-8. Users can easily #' override or update this vector. #' #' @section Bugs: #' The current mapping is not guaranteed to be fully reversible: some SQL #' identifiers that get mapped into R identifiers with `make.names` and #' then back to SQL with [make.db.names()] will not be equal to the #' original SQL identifiers (e.g., compound SQL identifiers of the form #' `username.tablename` will loose the dot ``.''). #' #' @references The set of SQL keywords is stored in the character vector #' `.SQL92Keywords` and reflects the SQL ANSI/ISO standard as documented #' in "X/Open SQL and RDA", 1994, ISBN 1-872630-68-8. Users can easily #' override or update this vector. #' @aliases #' make.db.names #' SQLKeywords #' isSQLKeyword #' @param dbObj any DBI object (e.g., `DBIDriver`). #' @param snames a character vector of R identifiers (symbols) from which we #' need to make SQL identifiers. #' @param name a character vector with database identifier candidates we need #' to determine whether they are legal SQL identifiers or not. #' @param unique logical describing whether the resulting set of SQL names #' should be unique. Its default is `TRUE`. Following the SQL 92 #' standard, uniqueness of SQL identifiers is determined regardless of whether #' letters are upper or lower case. #' @param allow.keywords logical describing whether SQL keywords should be #' allowed in the resulting set of SQL names. Its default is `TRUE` #' @param keywords a character vector with SQL keywords, by default it's #' `.SQL92Keywords` defined by the DBI. #' @param case a character string specifying whether to make the comparison as #' lower case, upper case, or any of the two. it defaults to `any`. #' @param \dots any other argument are passed to the driver implementation. #' @return `make.db.names` returns a character vector of legal SQL #' identifiers corresponding to its `snames` argument. #' #' `SQLKeywords` returns a character vector of all known keywords for the #' database-engine associated with `dbObj`. #' #' `isSQLKeyword` returns a logical vector parallel to `name`. #' @export setGeneric( "make.db.names", signature = c("dbObj", "snames"), function(dbObj, snames, keywords = .SQL92Keywords, unique = TRUE, allow.keywords = TRUE, ...) standardGeneric("make.db.names"), valueClass = "character" ) #' @rdname hidden_aliases setMethod("make.db.names", signature(dbObj="DBIObject", snames="character"), definition = function(dbObj, snames, keywords, unique, allow.keywords, ...) { make.db.names.default(snames, keywords, unique, allow.keywords) }, valueClass = "character" ) ## produce legal SQL identifiers from strings in a character vector ## unique, in this function, means unique regardless of lower/upper case #' @rdname make.db.names #' @export make.db.names.default <- function(snames, keywords = .SQL92Keywords, unique = TRUE, allow.keywords = TRUE) { makeUnique <- function(x, sep = "_") { if(length(x)==0) return(x) out <- x lc <- make.names(tolower(x), unique=FALSE) i <- duplicated(lc) lc <- make.names(lc, unique = TRUE) out[i] <- paste(out[i], substring(lc[i], first=nchar(out[i])+1), sep=sep) out } ## Note: SQL identifiers *can* be enclosed in double or single quotes ## when they are equal to reserverd keywords. fc <- substring(snames, 1, 1) lc <- substring(snames, nchar(snames)) i <- match(fc, c("'", '"'), 0)>0 & match(lc, c("'", '"'), 0)>0 snames[!i] <- make.names(snames[!i], unique=FALSE) if(unique) snames[!i] <- makeUnique(snames[!i]) if(!allow.keywords){ kwi <- match(keywords, toupper(snames), nomatch = 0L) snames[kwi] <- paste('"', snames[kwi], '"', sep='') } gsub("\\.", "_", snames) } #' @rdname make.db.names #' @export setGeneric( "isSQLKeyword", signature = c("dbObj", "name"), function(dbObj, name, keywords = .SQL92Keywords, case = c("lower", "upper", "any")[3], ...) standardGeneric("isSQLKeyword"), valueClass = "logical" ) #' @rdname hidden_aliases setMethod("isSQLKeyword", signature(dbObj="DBIObject", name="character"), definition = function(dbObj, name, keywords, case, ...) isSQLKeyword.default(name, keywords, case), valueClass = "logical" ) #' @rdname make.db.names #' @export isSQLKeyword.default <- function(name, keywords = .SQL92Keywords, case = c("lower", "upper", "any")[3]) { n <- pmatch(case, c("lower", "upper", "any"), nomatch=0) if(n==0) stop('case must be one of "lower", "upper", or "any"') kw <- switch(c("lower", "upper", "any")[n], lower = tolower(keywords), upper = toupper(keywords), any = toupper(keywords)) if(n==3) name <- toupper(name) match(name, keywords, nomatch=0) > 0 } ## SQL ANSI 92 (plus ISO's) keywords --- all 220 of them! ## (See pp. 22 and 23 in X/Open SQL and RDA, 1994, isbn 1-872630-68-8) #' @export setGeneric( "SQLKeywords", function(dbObj, ...) standardGeneric("SQLKeywords"), valueClass = "character" ) #' @rdname hidden_aliases setMethod("SQLKeywords", "DBIObject", definition = function(dbObj, ...) .SQL92Keywords, valueClass = "character" ) #' @rdname hidden_aliases setMethod("SQLKeywords", "missing", definition = function(dbObj, ...) .SQL92Keywords, valueClass = "character" ) #' @export .SQL92Keywords <- c("ABSOLUTE", "ADD", "ALL", "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC", "ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN", "BIT", "BIT_LENGTH", "BY", "CASCADE", "CASCADED", "CASE", "CAST", "CATALOG", "CHAR", "CHARACTER", "CHARACTER_LENGTH", "CHAR_LENGTH", "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION", "COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT", "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING", "COUNT", "CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIMESTAMP", "CURRENT_TYPE", "CURSOR", "DATE", "DAY", "DEALLOCATE", "DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE", "DEFERRED", "DELETE", "DESC", "DESCRIBE", "DESCRIPTOR", "DIAGNOSTICS", "DICONNECT", "DICTIONATRY", "DISPLACEMENT", "DISTINCT", "DOMAIN", "DOUBLE", "DROP", "ELSE", "END", "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC", "EXECUTE", "EXISTS", "EXTERNAL", "EXTRACT", "FALSE", "FETCH", "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND", "FROM", "FULL", "GET", "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING", "HOUR", "IDENTITY", "IGNORE", "IMMEDIATE", "IN", "INCLUDE", "INDEX", "INDICATOR", "INITIALLY", "INNER", "INPUT", "INSENSITIVE", "INSERT", "INT", "INTEGER", "INTERSECT", "INTERVAL", "INTO", "IS", "ISOLATION", "JOIN", "KEY", "LANGUAGE", "LAST", "LEFT", "LEVEL", "LIKE", "LOCAL", "LOWER", "MATCH", "MAX", "MIN", "MINUTE", "MODULE", "MONTH", "NAMES", "NATIONAL", "NCHAR", "NEXT", "NOT", "NULL", "NULLIF", "NUMERIC", "OCTECT_LENGTH", "OF", "OFF", "ONLY", "OPEN", "OPTION", "OR", "ORDER", "OUTER", "OUTPUT", "OVERLAPS", "PARTIAL", "POSITION", "PRECISION", "PREPARE", "PRESERVE", "PRIMARY", "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC", "READ", "REAL", "REFERENCES", "RESTRICT", "REVOKE", "RIGHT", "ROLLBACK", "ROWS", "SCHEMA", "SCROLL", "SECOND", "SECTION", "SELECT", "SET", "SIZE", "SMALLINT", "SOME", "SQL", "SQLCA", "SQLCODE", "SQLERROR", "SQLSTATE", "SQLWARNING", "SUBSTRING", "SUM", "SYSTEM", "TABLE", "TEMPORARY", "THEN", "TIME", "TIMESTAMP", "TIMEZONE_HOUR", "TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE", "TRANSLATION", "TRUE", "UNION", "UNIQUE", "UNKNOWN", "UPDATE", "UPPER", "USAGE", "USER", "USING", "VALUE", "VALUES", "VARCHAR", "VARYING", "VIEW", "WHEN", "WHENEVER", "WHERE", "WITH", "WORK", "WRITE", "YEAR", "ZONE" ) #' Call an SQL stored procedure #' #' DEPRECATED #' #' @inheritParams dbGetQuery #' @keywords internal #' @export setGeneric( "dbCallProc", def = function(conn, ...) { .Deprecated() standardGeneric("dbCallProc") } ) #' Determine the current version of the package. #' #' @export #' @keywords internal dbGetDBIVersion <- function() { .Deprecated("packageVersion('DBI')") utils::packageVersion("DBI") } #' Set data mappings between an DBMS and R. #' #' This generic is deprecated since no working implementation was ever produced. #' #' Sets one or more conversion functions to handle the translation of DBMS data #' types to R objects. This is only needed for non-primitive data, since all #' DBI drivers handle the common base types (integers, numeric, strings, etc.) #' #' The details on conversion functions (e.g., arguments, whether they can invoke #' initializers and/or destructors) have not been specified. #' #' @inheritParams dbClearResult #' @keywords internal #' @param flds a field description object as returned by `dbColumnInfo`. #' @export setGeneric( "dbSetDataMappings", def = function(res, flds, ...) { .Deprecated() standardGeneric("dbSetDataMappings") } ) DBI/R/hidden.R0000644000176200001440000000030713055622377012441 0ustar liggesusers#' Internal page for hidden aliases #' #' For S4 methods that require a documentation entry but only clutter the index. #' #' @usage NULL #' @format NULL #' @keywords internal hidden_aliases <- NULL DBI/R/util.R0000644000176200001440000000107013055622377012161 0ustar liggesusers#' Print a list of pairs. #' #' DEPRECATED, do not use. Use [base::summary()] to print output of #' [dbGetInfo()]. #' #' @param x a list of key, value pairs #' @param ... additional arguments to be passed to `cat` #' @return the (invisible) value of x. #' @keywords internal #' @export print.list.pairs print.list.pairs <- function(x, ...) { .Deprecated() print_list_pairs(x, ...) } print_list_pairs <- function(x, ...) { for(key in names(x)){ value <- format(x[[key]]) if (identical(value, "")) next cat(key, "=", value, "\n") } invisible(x) } DBI/R/transactions.R0000644000176200001440000001277613055622377013733 0ustar liggesusers#' Begin/commit/rollback SQL transactions #' #' A transaction encapsulates several SQL statements in an atomic unit. #' It is initiated with `dbBegin()` and either made persistent with `dbCommit()` #' or undone with `dbRollback()`. #' In any case, the DBMS guarantees that either all or none of the statements #' have a permanent effect. #' This helps ensuring consistency of write operations to multiple tables. #' #' Not all database engines implement transaction management, in which case #' these methods should not be implemented for the specific #' [DBIConnection-class] subclass. #' #' @inherit DBItest::spec_transaction_begin_commit_rollback return #' @inheritSection DBItest::spec_transaction_begin_commit_rollback Specification #' #' @inheritParams dbGetQuery #' @seealso Self-contained transactions: [dbWithTransaction()] #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "cash", data.frame(amount = 100)) #' dbWriteTable(con, "account", data.frame(amount = 2000)) #' #' # All operations are carried out as logical unit: #' dbBegin(con) #' withdrawal <- 300 #' dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal)) #' dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal)) #' dbCommit(con) #' #' dbReadTable(con, "cash") #' dbReadTable(con, "account") #' #' # Rolling back after detecting negative value on account: #' dbBegin(con) #' withdrawal <- 5000 #' dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal)) #' dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal)) #' if (dbReadTable(con, "account")$amount >= 0) { #' dbCommit(con) #' } else { #' dbRollback(con) #' } #' #' dbReadTable(con, "cash") #' dbReadTable(con, "account") #' #' dbDisconnect(con) #' @name transactions NULL #' @export #' @rdname transactions setGeneric("dbBegin", def = function(conn, ...) standardGeneric("dbBegin") ) #' @export #' @rdname transactions setGeneric("dbCommit", def = function(conn, ...) standardGeneric("dbCommit") ) #' @export #' @rdname transactions setGeneric("dbRollback", def = function(conn, ...) standardGeneric("dbRollback") ) #' Self-contained SQL transactions #' #' Given that \link{transactions} are implemented, this function #' allows you to pass in code that is run in a transaction. #' The default method of `dbWithTransaction()` calls [dbBegin()] #' before executing the code, #' and [dbCommit()] after successful completion, #' or [dbRollback()] in case of an error. #' The advantage is #' that you don't have to remember to do `dbBegin()` and `dbCommit()` or #' `dbRollback()` -- that is all taken care of. #' The special function `dbBreak()` allows an early exit with rollback, #' it can be called only inside `dbWithTransaction()`. #' #' DBI implements `dbWithTransaction()`, backends should need to override this #' generic only if they implement specialized handling. #' @inherit DBItest::spec_transaction_with_transaction return #' @inheritSection DBItest::spec_transaction_with_transaction Specification #' #' @inheritParams dbGetQuery #' @param code An arbitrary block of R code. #' #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "cash", data.frame(amount = 100)) #' dbWriteTable(con, "account", data.frame(amount = 2000)) #' #' # All operations are carried out as logical unit: #' dbWithTransaction( #' con, #' { #' withdrawal <- 300 #' dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal)) #' dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal)) #' } #' ) #' #' # The code is executed as if in the curent environment: #' withdrawal #' #' # The changes are committed to the database after successful execution: #' dbReadTable(con, "cash") #' dbReadTable(con, "account") #' #' # Rolling back with dbBreak(): #' dbWithTransaction( #' con, #' { #' withdrawal <- 5000 #' dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal)) #' dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal)) #' if (dbReadTable(con, "account")$amount < 0) { #' dbBreak() #' } #' } #' ) #' #' # These changes were not committed to the database: #' dbReadTable(con, "cash") #' dbReadTable(con, "account") #' #' dbDisconnect(con) setGeneric("dbWithTransaction", def = function(conn, code, ...) standardGeneric("dbWithTransaction") ) #' @rdname hidden_aliases #' @export setMethod("dbWithTransaction", "DBIConnection", function(conn, code) { ## needs to be a closure, because it accesses conn rollback_because <- function(e) { call <- dbRollback(conn) if (identical(call, FALSE)) { stop(paste("Failed to rollback transaction.", "Tried to roll back because an error", "occurred:", conditionMessage(e)), call. = FALSE) } if (inherits(e, "error")) { stop(e) } } ## check if each operation is successful call <- dbBegin(conn) if (identical(call, FALSE)) { stop("Failed to begin transaction", call. = FALSE) } tryCatch( { res <- force(code) call <- dbCommit(conn) if (identical(call, FALSE)) { stop("Failed to commit transaction", call. = FALSE) } res }, dbi_abort = rollback_because, error = rollback_because) }) #' @export #' @rdname dbWithTransaction dbBreak <- function() { signalCondition( structure( list(message = "Aborting DBI processing", call = NULL), class = c("dbi_abort", "condition"))) stop("Invalid usage of dbBreak().", call. = FALSE) } DBI/R/table.R0000644000176200001440000000152613055622377012301 0ustar liggesusers#' @rdname Table setClass("Table", slots = list(name = "character")) #' Refer to a table nested in a hierarchy (e.g. within a schema) #' #' @param ... Components of the hierarchy, e.g. `schema`, `table`, #' or `cluster`, `catalog`, `schema`, `table`. #' For more on these concepts, see #' \url{http://stackoverflow.com/questions/7022755/} Table <- function(...) { new("Table", name = c(...)) } #' @rdname hidden_aliases #' @param conn,x Connection and Table used when escaping. #' @export setMethod("dbQuoteIdentifier", c("DBIConnection", "Table"), function(conn, x, ...) { SQL(paste0(dbQuoteIdentifier(conn, x@name), collapse = ".")) } ) #' @rdname hidden_aliases #' @param object Table object to print #' @export setMethod("show", "Table", function(object) { cat(" ", paste0(object@name, collapse = "."), "\n", sep = "") }) DBI/R/table-insert.R0000644000176200001440000000442513055622377013604 0ustar liggesusers#' Insert rows into a table #' #' `sqlAppendTable` generates a single SQL string that inserts a #' data frame into an existing table. `sqlAppendTableTemplate` generates #' a template suitable for use with [dbBind()]. #' These methods are mostly useful for backend implementers. #' #' @inheritParams sqlCreateTable #' @inheritParams rownames #' @param values A data frame. Factors will be converted to character vectors. #' Character vectors will be escaped with [dbQuoteString()]. #' @family SQL generation #' @export #' @examples #' sqlAppendTable(ANSI(), "iris", head(iris)) #' #' sqlAppendTable(ANSI(), "mtcars", head(mtcars)) #' sqlAppendTable(ANSI(), "mtcars", head(mtcars), row.names = FALSE) setGeneric( "sqlAppendTable", function(con, table, values, row.names = NA, ...) standardGeneric("sqlAppendTable") ) #' @rdname hidden_aliases #' @export setMethod("sqlAppendTable", "DBIConnection", function(con, table, values, row.names = NA, ...) { stopifnot(is.data.frame(values)) sql_values <- sqlData(con, values, row.names) table <- dbQuoteIdentifier(con, table) fields <- dbQuoteIdentifier(con, names(sql_values)) # Convert fields into a character matrix rows <- do.call(paste, c(sql_values, sep = ", ")) SQL(paste0( "INSERT INTO ", table, "\n", " (", paste(fields, collapse = ", "), ")\n", "VALUES\n", paste0(" (", rows, ")", collapse = ",\n") )) } ) #' @rdname sqlAppendTable #' @inheritParams sqlCreateTable #' @inheritParams sqlAppendTable #' @inheritParams rownames #' @param prefix Parameter prefix to put in front of column id. #' @export #' @examples #' sqlAppendTableTemplate(ANSI(), "iris", iris) #' #' sqlAppendTableTemplate(ANSI(), "mtcars", mtcars) #' sqlAppendTableTemplate(ANSI(), "mtcars", mtcars, row.names = FALSE) sqlAppendTableTemplate <- function(con, table, values, row.names = NA, prefix = "?", ...) { table <- dbQuoteIdentifier(con, table) values <- sqlRownamesToColumn(values[0, , drop = FALSE], row.names) fields <- dbQuoteIdentifier(con, names(values)) # Convert fields into a character matrix SQL(paste0( "INSERT INTO ", table, "\n", " (", paste(fields, collapse = ", "), ")\n", "VALUES\n", paste0(" (", paste0(prefix, seq_along(fields), collapse = ", "), ")", collapse = ",\n") )) } DBI/R/DBConnection.R0000644000176200001440000003452413070010370013500 0ustar liggesusers#' DBIConnection class #' #' This virtual class encapsulates the connection to a DBMS, and it provides #' access to dynamic queries, result sets, DBMS session management #' (transactions), etc. #' #' @section Implementation note: #' Individual drivers are free to implement single or multiple simultaneous #' connections. #' #' @docType class #' @name DBIConnection-class #' @family DBI classes #' @family DBIConnection generics #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' con #' dbDisconnect(con) #' #' \dontrun{ #' con <- dbConnect(RPostgreSQL::PostgreSQL(), "username", "passsword") #' con #' dbDisconnect(con) #' } #' @export #' @include DBObject.R setClass("DBIConnection", contains = c("DBIObject", "VIRTUAL")) #' @rdname hidden_aliases #' @param object Object to display #' @export setMethod("show", "DBIConnection", function(object) { # to protect drivers that fail to implement the required methods (e.g., # RPostgreSQL) tryCatch( show_connection(object), error = function(e) NULL) invisible(NULL) }) show_connection <- function(object) { cat("<", is(object)[1], ">\n", sep = "") if (!dbIsValid(object)) { cat(" DISCONNECTED\n") } } #' Disconnect (close) a connection #' #' This closes the connection, discards all pending work, and frees #' resources (e.g., memory, sockets). #' #' @inherit DBItest::spec_connection_disconnect return #' @inheritSection DBItest::spec_connection_disconnect Specification #' #' @inheritParams dbGetQuery #' @family DBIConnection generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' dbDisconnect(con) setGeneric("dbDisconnect", def = function(conn, ...) standardGeneric("dbDisconnect") ) #' Execute a query on a given database connection #' #' The `dbSendQuery()` method only submits and synchronously executes the #' SQL query to the database engine. It does \emph{not} extract any #' records --- for that you need to use the [dbFetch()] method, and #' then you must call [dbClearResult()] when you finish fetching the #' records you need. For interactive use, you should almost always prefer #' [dbGetQuery()]. #' #' This method is for `SELECT` queries only. Some backends may #' support data manipulation queries through this method for compatibility #' reasons. However, callers are strongly encouraged to use #' [dbSendStatement()] for data manipulation statements. #' #' The query is submitted to the database server and the DBMS executes it, #' possibly generating vast amounts of data. Where these data live #' is driver-specific: some drivers may choose to leave the output on the server #' and transfer them piecemeal to R, others may transfer all the data to the #' client -- but not necessarily to the memory that R manages. See individual #' drivers' `dbSendQuery()` documentation for details. #' @inherit DBItest::spec_result_send_query return #' @inheritSection DBItest::spec_result_send_query Specification #' #' @inheritParams dbGetQuery #' @param statement a character string containing SQL. #' #' @family DBIConnection generics #' @seealso For updates: [dbSendStatement()] and [dbExecute()]. #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars) #' rs <- dbSendQuery(con, "SELECT * FROM mtcars WHERE cyl = 4;") #' dbFetch(rs) #' dbClearResult(rs) #' #' dbDisconnect(con) #' @export setGeneric("dbSendQuery", def = function(conn, statement, ...) standardGeneric("dbSendQuery"), valueClass = "DBIResult" ) #' Execute a data manipulation statement on a given database connection #' #' The `dbSendStatement()` method only submits and synchronously executes the #' SQL data manipulation statement (e.g., `UPDATE`, `DELETE`, #' `INSERT INTO`, `DROP TABLE`, ...) to the database engine. To query #' the number of affected rows, call [dbGetRowsAffected()] on the #' returned result object. You must also call [dbClearResult()] after #' that. For interactive use, you should almost always prefer #' [dbExecute()]. #' #' [dbSendStatement()] comes with a default implementation that simply #' forwards to [dbSendQuery()], to support backends that only #' implement the latter. #' #' @inherit DBItest::spec_result_send_statement return #' @inheritSection DBItest::spec_result_send_statement Specification #' #' @inheritParams dbGetQuery #' @param statement a character string containing SQL. #' #' @family DBIConnection generics #' @seealso For queries: [dbSendQuery()] and [dbGetQuery()]. #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "cars", head(cars, 3)) #' rs <- dbSendStatement(con, #' "INSERT INTO cars (speed, dist) VALUES (1, 1), (2, 2), (3, 3);") #' dbHasCompleted(rs) #' dbGetRowsAffected(rs) #' dbClearResult(rs) #' dbReadTable(con, "cars") # there are now 6 rows #' #' dbDisconnect(con) #' @export setGeneric("dbSendStatement", def = function(conn, statement, ...) standardGeneric("dbSendStatement"), valueClass = "DBIResult" ) #' @rdname hidden_aliases #' @export setMethod( "dbSendStatement", signature("DBIConnection", "character"), function(conn, statement, ...) { dbSendQuery(conn, statement, ...) } ) #' Send query, retrieve results and then clear result set #' #' Returns the result of a query as a data frame. #' `dbGetQuery()` comes with a default implementation #' (which should work with most backends) that calls #' [dbSendQuery()], then [dbFetch()], ensuring that #' the result is always free-d by [dbClearResult()]. #' #' This method is for `SELECT` queries only. Some backends may #' support data manipulation statements through this method for compatibility #' reasons. However, callers are strongly advised to use #' [dbExecute()] for data manipulation statements. #' #' @inherit DBItest::spec_result_get_query return #' @inheritSection DBItest::spec_result_get_query Specification #' #' @section Implementation notes: #' Subclasses should override this method only if they provide some sort of #' performance optimization. #' #' @param conn A [DBIConnection-class] object, as returned by #' [dbConnect()]. #' @param statement a character string containing SQL. #' @param ... Other parameters passed on to methods. #' @family DBIConnection generics #' @seealso For updates: [dbSendStatement()] and [dbExecute()]. #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars) #' dbGetQuery(con, "SELECT * FROM mtcars") #' #' dbDisconnect(con) setGeneric("dbGetQuery", def = function(conn, statement, ...) standardGeneric("dbGetQuery") ) #' @rdname hidden_aliases #' @export setMethod("dbGetQuery", signature("DBIConnection", "character"), function(conn, statement, ...) { rs <- dbSendQuery(conn, statement, ...) on.exit(dbClearResult(rs)) df <- dbFetch(rs, n = -1, ...) if (!dbHasCompleted(rs)) { warning("Pending rows", call. = FALSE) } df } ) #' Execute an update statement, query number of rows affected, and then close result set #' #' Executes a statement and returns the number of rows affected. #' `dbExecute()` comes with a default implementation #' (which should work with most backends) that calls #' [dbSendStatement()], then [dbGetRowsAffected()], ensuring that #' the result is always free-d by [dbClearResult()]. #' #' @section Implementation notes: #' Subclasses should override this method only if they provide some sort of #' performance optimization. #' #' @inherit DBItest::spec_result_execute return #' #' @inheritParams dbGetQuery #' @param statement a character string containing SQL. #' @family DBIConnection generics #' @seealso For queries: [dbSendQuery()] and [dbGetQuery()]. #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "cars", head(cars, 3)) #' dbReadTable(con, "cars") # there are 3 rows #' dbExecute(con, #' "INSERT INTO cars (speed, dist) VALUES (1, 1), (2, 2), (3, 3);") #' dbReadTable(con, "cars") # there are now 6 rows #' #' dbDisconnect(con) setGeneric( "dbExecute", def = function(conn, statement, ...) standardGeneric("dbExecute") ) #' @rdname hidden_aliases #' @export setMethod( "dbExecute", signature("DBIConnection", "character"), function(conn, statement, ...) { rs <- dbSendStatement(conn, statement, ...) on.exit(dbClearResult(rs)) dbGetRowsAffected(rs) } ) #' Get DBMS exceptions #' #' @inheritParams dbGetQuery #' @family DBIConnection generics #' @return a list with elements `errorNum` (an integer error number) and #' `errorMsg` (a character string) describing the last error in the #' connection `conn`. #' @export setGeneric("dbGetException", def = function(conn, ...) standardGeneric("dbGetException") ) #' A list of all pending results #' #' List of [DBIResult-class] objects currently active on the connection. #' #' @inheritParams dbGetQuery #' @family DBIConnection generics #' @return a list. If no results are active, an empty list. If only #' a single result is active, a list with one element. #' @export setGeneric("dbListResults", def = function(conn, ...) standardGeneric("dbListResults") ) #' List field names of a remote table #' #' @inheritParams dbGetQuery #' @param name a character string with the name of the remote table. #' @return a character vector #' @family DBIConnection generics #' @seealso [dbColumnInfo()] to get the type of the fields. #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars) #' dbListFields(con, "mtcars") #' #' dbDisconnect(con) setGeneric("dbListFields", def = function(conn, name, ...) standardGeneric("dbListFields"), valueClass = "character" ) #' List remote tables #' #' Returns the unquoted names of remote tables accessible through this #' connection. #' This should, where possible, include temporary tables, and views. #' #' @inherit DBItest::spec_sql_list_tables return #' @inheritSection DBItest::spec_sql_list_tables Additional arguments #' #' @inheritParams dbGetQuery #' @family DBIConnection generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbListTables(con) #' dbWriteTable(con, "mtcars", mtcars) #' dbListTables(con) #' #' dbDisconnect(con) setGeneric("dbListTables", def = function(conn, ...) standardGeneric("dbListTables"), valueClass = "character" ) #' Copy data frames from database tables #' #' Reads a database table to a data frame, optionally converting #' a column to row names and converting the column names to valid #' R identifiers. #' #' @inherit DBItest::spec_sql_read_table return #' @inheritSection DBItest::spec_sql_read_table Additional arguments #' @inheritSection DBItest::spec_sql_read_table Specification #' #' @inheritParams dbGetQuery #' @param name A character string specifying the unquoted DBMS table name, #' or the result of a call to [dbQuoteIdentifier()]. #' @family DBIConnection generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars[1:10, ]) #' dbReadTable(con, "mtcars") #' #' dbDisconnect(con) setGeneric("dbReadTable", valueClass = "data.frame", signature = c("conn", "name"), function(conn, name, ...) standardGeneric("dbReadTable") ) #' @rdname hidden_aliases #' @export setMethod("dbReadTable", c("DBIConnection", "character"), function(conn, name, ..., row.names = NA, check.names = TRUE) { sql_name <- dbQuoteIdentifier(conn, x = name, ...) if (length(sql_name) != 1L) { stop("Invalid name: ", format(name), call. = FALSE) } stopifnot(length(row.names) == 1L) stopifnot(is.null(row.names) || is.logical(row.names) || is.character(row.names)) stopifnot(length(check.names) == 1L) stopifnot(is.logical(check.names)) stopifnot(!is.na(check.names)) out <- dbGetQuery(conn, paste0("SELECT * FROM ", sql_name)) out <- sqlColumnToRownames(out, row.names) if (check.names) { names(out) <- make.names(names(out), unique = TRUE) } out } ) #' Copy data frames to database tables #' #' Writes, overwrites or appends a data frame to a database table, optionally #' converting row names to a column and specifying SQL data types for fields. #' #' @inherit DBItest::spec_sql_write_table return #' @inheritSection DBItest::spec_sql_write_table Additional arguments #' @inheritSection DBItest::spec_sql_write_table Specification #' #' @inheritParams dbGetQuery #' @inheritParams dbReadTable #' @param value a [data.frame] (or coercible to data.frame). #' @family DBIConnection generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbWriteTable(con, "mtcars", mtcars[1:5, ]) #' dbReadTable(con, "mtcars") #' #' dbWriteTable(con, "mtcars", mtcars[6:10, ], append = TRUE) #' dbReadTable(con, "mtcars") #' #' dbWriteTable(con, "mtcars", mtcars[1:10, ], overwrite = TRUE) #' dbReadTable(con, "mtcars") #' #' # No row names #' dbWriteTable(con, "mtcars", mtcars[1:10, ], overwrite = TRUE, row.names = FALSE) #' dbReadTable(con, "mtcars") #' #' @export setGeneric("dbWriteTable", signature = c("conn", "name", "value"), function(conn, name, value, ...) standardGeneric("dbWriteTable") ) #' Does a table exist? #' #' Returns if a table given by name exists in the database. #' #' @inherit DBItest::spec_sql_exists_table return #' @inheritSection DBItest::spec_sql_exists_table Additional arguments #' @inheritSection DBItest::spec_sql_exists_table Specification #' #' @inheritParams dbGetQuery #' @param name A character string specifying a DBMS table name. #' @family DBIConnection generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbExistsTable(con, "iris") #' dbWriteTable(con, "iris", iris) #' dbExistsTable(con, "iris") #' #' dbDisconnect(con) setGeneric("dbExistsTable", def = function(conn, name, ...) standardGeneric("dbExistsTable"), valueClass = "logical" ) #' Remove a table from the database #' #' Remove a remote table (e.g., created by [dbWriteTable()]) #' from the database. #' #' @inherit DBItest::spec_sql_remove_table return #' @inheritSection DBItest::spec_sql_remove_table Specification #' #' @inheritParams dbGetQuery #' @param name A character string specifying a DBMS table name. #' @family DBIConnection generics #' @export #' @examples #' con <- dbConnect(RSQLite::SQLite(), ":memory:") #' #' dbExistsTable(con, "iris") #' dbWriteTable(con, "iris", iris) #' dbExistsTable(con, "iris") #' dbRemoveTable(con, "iris") #' dbExistsTable(con, "iris") #' #' dbDisconnect(con) setGeneric("dbRemoveTable", def = function(conn, name, ...) standardGeneric("dbRemoveTable") ) DBI/R/table-create.R0000644000176200001440000000412313055622377013536 0ustar liggesusers#' Create a simple table #' #' Exposes interface to simple `CREATE TABLE` commands. The default #' method is ANSI SQL 99 compliant. #' This method is mostly useful for backend implementers. #' #' @section DBI-backends: #' If you implement one method (i.e. for strings or data frames), you need #' to implement both, otherwise the S4 dispatch rules will be ambiguous #' and will generate an error on every call. #' #' @param con A database connection. #' @param table Name of the table. Escaped with #' [dbQuoteIdentifier()]. #' @param fields Either a character vector or a data frame. #' #' A named character vector: Names are column names, values are types. #' Names are escaped with [dbQuoteIdentifier()]. #' Field types are unescaped. #' #' A data frame: field types are generated using #' [dbDataType()]. #' @param temporary If `TRUE`, will generate a temporary table statement. #' @inheritParams rownames #' @param ... Other arguments used by individual methods. #' @export #' @examples #' sqlCreateTable(ANSI(), "my-table", c(a = "integer", b = "text")) #' sqlCreateTable(ANSI(), "my-table", iris) #' #' # By default, character row names are converted to a row_names colum #' sqlCreateTable(ANSI(), "mtcars", mtcars[, 1:5]) #' sqlCreateTable(ANSI(), "mtcars", mtcars[, 1:5], row.names = FALSE) setGeneric( "sqlCreateTable", function(con, table, fields, row.names = NA, temporary = FALSE, ...) standardGeneric("sqlCreateTable") ) #' @rdname hidden_aliases #' @export setMethod("sqlCreateTable", "DBIConnection", function(con, table, fields, row.names = NA, temporary = FALSE, ...) { table <- dbQuoteIdentifier(con, table) if (is.data.frame(fields)) { fields <- sqlRownamesToColumn(fields, row.names) fields <- vapply(fields, function(x) DBI::dbDataType(con, x), character(1)) } field_names <- dbQuoteIdentifier(con, names(fields)) field_types <- unname(fields) fields <- paste0(field_names, " ", field_types) SQL(paste0( "CREATE ", if (temporary) "TEMPORARY ", "TABLE ", table, " (\n", " ", paste(fields, collapse = ",\n "), "\n)\n" )) } ) DBI/R/DBI-package.R0000644000176200001440000000132613060005002013147 0ustar liggesusers#' @description #' DBI defines an interface 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 (so-called *DBI backends*). #' #' @inheritSection DBItest::DBIspec Definition #' @inheritSection DBItest::DBIspec DBI classes and methods #' @inheritSection DBItest::DBIspec Construction of the DBIDriver object #' #' @examples #' RSQLite::SQLite() #' @seealso #' Important generics: [dbConnect()], [dbGetQuery()], #' [dbReadTable()], [dbWriteTable()], [dbDisconnect()] #' #' Formal specification (currently work in progress and incomplete): #' `vignette("spec", package = "DBI")` "_PACKAGE" DBI/R/ANSI.R0000644000176200001440000000061413055622377011741 0ustar liggesusers#' @include DBConnection.R #' @include DBDriver.R setClass("AnsiConnection", contains = "DBIConnection") #' A dummy DBI connector that simulates ANSI-SQL compliance #' #' @export #' @keywords internal #' @examples #' ANSI() ANSI <- function() { new("AnsiConnection") } #' @rdname hidden_aliases #' @export setMethod("show", "AnsiConnection", function(object) { cat("\n") }) DBI/vignettes/0000755000176200001440000000000013070016501012651 5ustar liggesusersDBI/vignettes/backend.Rmd0000644000176200001440000002343413027447303014724 0ustar liggesusers --- title: "Implementing a new backend" author: "Hadley Wickham" date: "`r Sys.Date()`" output: rmarkdown::html_vignette vignette: > %\VignetteIndexEntry{Implementing a new backend} %\VignetteEngine{knitr::rmarkdown} \usepackage[utf8]{inputenc} --- ```{r, echo = FALSE} library(DBI) knitr::opts_chunk$set(collapse = TRUE, comment = "#>") ``` The goal of this document is to help you implement a new backend for DBI. If you are writing a package that connects a database to R, I highly recommend that you make it DBI compatible because it makes your life easier by spelling out exactly what you need to do. The consistent interface provided by DBI makes it easier for you to implement the package (because you have fewer arbitrary choices to make), and easier for your users (because it follows a familiar pattern). In addition, the `DBItest` package provides test cases which you can easily incorporate in your package. I'll illustrate the process using a fictional database called Kazam. ## Getting started Start by creating a package. It's up to you what to call the package, but following the existing pattern of `RSQLite`, `RMySQL`, `RPostgres` and `ROracle` will make it easier for people to find it. For this example, I'll call my package `RKazam`. In your `DESCRIPTION`, make sure to include: ```yaml Imports: DBI (>= 0.3.0), methods Suggests: DBItest, testthat ``` Importing `DBI` is fine, because your users are not supposed to *attach* your package anyway; the preferred method is to attach `DBI` and use explicit qualification via `::` to access the driver in your package (which needs to be done only once). ## Testing Why testing at this early stage? Because testing should be an integral part of the software development cycle. Test right from the start, add automated tests as you go, finish faster (because tests are automated) while maintaining superb code quality (because tests also check corner cases that you might not be aware of). Don't worry: if some test cases are difficult or impossible to satisfy, or take too long to run, you can just turn them off. Take the time now to head over to the `DBItest` vignette. You will find a vast amount of ready-to-use test cases that will help you in the process of implementing your new DBI backend. ```r vignette("test", package = "DBItest") ``` Add custom tests that are not covered by `DBItest` at your discretion, or enhance `DBItest` and file a pull request if the test is generic enough to be useful for many DBI backends. ## Driver Start by making a driver class which inherits from `DBIDriver`. This class doesn't need to do anything, it's just used to dispatch other generics to the right method. Users don't need to know about this, so you can remove it from the default help listing with `@keywords internal`: ```{r} #' Driver for Kazam database. #' #' @keywords internal #' @export #' @import DBI #' @import methods setClass("KazamDriver", contains = "DBIDriver") ``` The driver class was more important in older versions of DBI, so you should also provide a dummy `dbUnloadDriver()` method. ```{r} #' @export #' @rdname Kazam-class setMethod("dbUnloadDriver", "KazamDriver", function(drv, ...) { TRUE }) ``` If your package needs global setup or tear down, do this in the `.onLoad()` and `.onUnload()` functions. You might also want to add a show method so the object prints nicely: ```{r} setMethod("show", "KazamDriver", function(object) { cat("\n") }) ``` Next create `Kazam()` which instantiates this class. ```{r} #' @export Kazam <- function() { new("KazamDriver") } Kazam() ``` ## Connection Next create a connection class that inherits from `DBIConnection`. This should store all the information needed to connect to the database. If you're talking to a C api, this will include a slot that holds an external pointer. ```{r} #' Kazam connection class. #' #' @export #' @keywords internal setClass("KazamConnection", contains = "DBIConnection", slots = list( host = "character", username = "character", # and so on ptr = "externalptr" ) ) ``` Now you have some of the boilerplate out of the way, you can start work on the connection. The most important method here is `dbConnect()` which allows you to connect to a specified instance of the database. Note the use of `@rdname Kazam`. This ensures that `Kazam()` and the connect method are documented together. ```{r} #' @param drv An object created by \code{Kazam()} #' @rdname Kazam #' @export #' @examples #' \dontrun{ #' db <- dbConnect(RKazam::Kazam()) #' dbWriteTable(db, "mtcars", mtcars) #' dbGetQuery(db, "SELECT * FROM mtcars WHERE cyl == 4") #' } setMethod("dbConnect", "KazamDriver", function(drv, ...) { # ... new("KazamConnection", host = host, ...) }) ``` * Replace `...` with the arguments needed to connect to your database. You'll always need to include `...` in the arguments, even if you don't use it, for compatibility with the generic. * This is likely to be where people first come for help, so the examples should show how to connect to the database, and how to query it. (Obviously these examples won't work yet.) Ideally, include examples that can be run right away (perhaps relying on a publicly hosted database), but failing that surround in `\dontrun{}` so people can at least see the code. Next, implement `show()` and `dbDisconnect()` methods. ## Results Finally, you're ready to implement the meat of the system: fetching results of a query into a data frame. First define a results class: ```{r} #' Kazam results class. #' #' @keywords internal #' @export setClass("KazamResult", contains = "DBIResult", slots = list(ptr = "externalptr") ) ``` Then write a `dbSendQuery()` method. This takes a connection and SQL string as arguments, and returns a result object. Again `...` is needed for compatibility with the generic, but you can add other arguments if you need them. ```{r} #' Send a query to Kazam. #' #' @export #' @examples #' # This is another good place to put examples setMethod("dbSendQuery", "KazamConnection", function(conn, statement, ...) { # some code new("KazamResult", ...) }) ``` Next, implement `dbClearResult()`, which should close the result set and free all resources associated with it: ```{r} #' @export setMethod("dbClearResult", "KazamResult", function(res, ...) { # free resources TRUE }) ``` The hardest part of every DBI package is writing the `dbFetch()` method. This needs to take a result set and (optionally) number of records to return, and create a dataframe. Mapping R's data types to those of your database may require a custom implementation of the `dbDataType()` method for your connection class: ```{r} #' Retrieve records from Kazam query #' @export setMethod("dbFetch", "KazamResult", function(res, n = -1, ...) { ... }) # (optionally) #' Find the database data type associated with an R object #' @export setMethod("dbDataType", "KazamConnection", function(dbObj, obj, ...) { ... }) ``` Next, implement `dbHasCompleted()` which should return a `logical` indicating if there are any rows remaining to be fetched. ```{r} #' @export setMethod("dbHasCompleted", "KazamResult", function(res, ...) { }) ``` With these four methods in place, you can now use the default `dbGetQuery()` to send a query to the database, retrieve results if available and then clean up. Spend some time now making sure this works with an existing database, or relax and let the `DBItest` package do the work for you. ## SQL methods You're now on the home stretch, and can make your wrapper substantially more useful by implementing methods that wrap around variations in SQL across databases: * `dbQuoteString()` and `dbQuoteIdentifer()` are used to safely quote strings and identifiers to avoid SQL injection attacks. Note that the former must be vectorized, but not the latter. * `dbWriteTable()` creates a database table given an R dataframe. I'd recommend using the functions prefixed with `sql` in this package to generate the SQL. These functions are still a work in progress so please let me know if you have problems. * `dbReadTable()`: a simple wrapper around `SELECT * FROM table`. Use `dbQuoteIdentifer()` to safely quote the table name and prevent mismatches between the names allowed by R and the database. * `dbListTables()` and `dbExistsTable()` let you determine what tables are available. If not provided by your database's API, you may need to generate sql that inspects the system tables. * `dbListFields()` shows which fields are available in a given table. * `dbRemoveTable()` wraps around `DROP TABLE`. Start with `SQL::sqlTableDrop()`. * `dbBegin()`, `dbCommit()` and `dbRollback()`: implement these three functions to provide basic transaction support. This functionality is currently not tested in the `DBItest` package. ## Metadata methods There are a lot of extra metadata methods for result sets (and one for the connection) that you might want to implement. They are described in the following. * `dbIsValid()` returns if a connection or a result set is open (`TRUE`) or closed (`FALSE`). All further methods in this section are valid for result sets only. * `dbGetStatement()` returns the issued query as a character value. * `dbColumnInfo()` lists the names and types of the result set's columns. * `dbGetRowCount()` and `dbGetRowsAffected()` returns the number of rows returned or altered in a `SELECT` or `INSERT`/`UPDATE` query, respectively. * `dbBind()` allows using parametrised queries. Take a look at `sqlInterpolate()` and `sqlParseVariables()` if your SQL engine doesn't offer native parametrised queries. ## Full DBI compliance By now, your package should implement all methods defined in the DBI specification. If you want to walk the extra mile, offer a read-only mode that allows your users to be sure that their valuable data doesn't get destroyed inadvertently. DBI/vignettes/hierarchy.png0000644000176200001440000022345512721354656015372 0ustar liggesusersPNG  IHDRJPwFiCCPICC Profile(c``RH,(a``+) rwRR` \\À|/­+JI-N8;1doyId$e @"- v:}¾V dl&]| SR@0$AIjE v/,L(QpTg^)(!?ÓQ B bs$20A20,a`S3d`g`7' j #1!>CI pHYsgR@IDATx |չHH&  hPTIe K [B@?JQ[*P-޲IPH,H s dO&3gY|uf9K<@@@@@<4@ذaǻt `\,/@@D% 7nL6M#8T':^*C@Hzڏ uԑiԨH` 8u D@(Sfgp     $Jݼi    -@l#@@@@@7 QL@@@@@leq    R7`    e (-ۈ3@@@@@Hy<@@@@([DiF    n.@;!    @$J6 @@@@psn4@@@@ QZg     (uy     PҲ8@@@@\Dw0C@@@@Hm     $Jݼi    -@l#@@@@@7 QL@@@@@leq    R7`    e (-ۈ3@@@@@Hy<@@@@([DiF    n.y 6liӦN>}z"    QhqCX~R[xڵR_E@k\__t[Q>G@-GI) M믿[Y&+)IrѶnZZ֯RCO~;i>VsbDZU @@L,@ĝG  sr%=zWn4[lH{*;O~-HlZb™#ẻҩ;^fj#~ [I{9)4E@՛,}#`9nqv\N$%Jbbw 40   ++  PQ$[=[̅$wy!""=.nڟ]f7LSx %ݝrIrL_P-G$*($2%}dOjM,JçΖ-}1Yp XBs˜n 3[S},~5RXğ8+\>(CW4ms5ںrĆ @1Z<ت3IOmeOl=%@,**Y\3om|^T<mX}@d>v}uMD 욾 5Jݻm*a݆^ =KOd\4ٿȽIKWHU[1)*[k>[#z^-[lۏr2ܡeW-'@@"va@@|idL I4r>LJIm6g 7rtUE'=&'SR$99Y\cwѤdLcZ!ٳg:_>}:)+9~IIH5'M}`璚-i22zUx2)fd1v4hGVK^Jt"u#I<{fH$czrG- )e|{\IO=$K/5H=cg"j)}'Y^mGW?ID驒} 39AL+/5ef9*)F_SjIv1Ҕ2e@@{ 3{HY  `mʮ]QF)R.yhOPc&ʢըlY:OF[%YWT,mNY*~mlG}T8Iʙ_8>} ir~Iz>t(jhAg$hWW&eK wA|2$@滄Γ8ԢǞldjppHbMZ.2w+v1Kdͨlc3'vcUewK\I^˼,0c iذL8 v@L'Ru# irW(1sB$UeIfF.'ON*H'r.@!ŮR,?IoTf!3[IRuOƨ׊$$X&.FRH,6Ij$:M$Um_mlZ#taXѩAdn ?P8 @@$JH  @91,cd%D,bsJ55Br̤tNދN brZ <`34ӷe?YuBL-%Sn7FuNۃXumZ$:i\g=VdSEO-#V/F&Wr͔M?ʢkEH\֏3~' 7퓬V/LxBN /|^p̜INd n|  `w۝@SH)'k˙id_ۨƻN#i6Pߚ_Ίs%-\P&%-/iY )!ӈǟ.Z/4hXmW*.LI[o6elհ]ؿΔr-hQH_닋Bnэ4@hf2  @u xo&[/i,и]JZr:zUDTzgȚw^)L"|,F^{Pef-[UnFī  H:Κ@@*+_^l׽̍f>؍*[-! xkzN_R@@ -ؼm$r@@ (u*?# K?X]2SBك)8|D>!ߋ`4i09 @@8s  .&%!Q$θeggKI&J|" TEOUZ@@ q   `OS@@@@@$JMm     QjOMB@@@@S (5e4    SD=5) @@@@L)@ԔF     `OԤ,@@@@0RSvA#    =HS@@@@@$JMm     QjOMB@@@@S (5e4    SD=5) @@@@L)@ԔF     `OԤ,@@@@0RSvA#    =HS@@@@@$JMm     QjOMB@@@@S (5e4    S˞Q O2ydiР $@3g̛7$@@MFq[h  ,;wt@ x{{s=W+8@!@    `RSw#    =HC2@@@@@$JM}     QjE@@@@@S (5u<    CD=)@@@@L-@G W̙3 @ϟ7E !@5(@k׮ɲedРA /xDid[n>9 O,- ^  i$J=i/ Nؽ{e„ BJ8}$%%`ddv]v%66Vڷo/cƌuIvvٛF  P 5ʥH@pT=ztɒ%#G#GJƍ=\ Ç_ۗx\Yj۷Ohӈ Zj٭ B@ (5o9 .'puٰae:A#\:$J]/<%vڵkE%MSRRdС)?N@(FDi1(< otrt͚5jv+=RDGv4Z-ojei @@Z@@ZZXB'HHRݱc4k^UP P-Z^{Mj3<#wyN@pǴ@ ͛urһ׿{ҹsgAA |AQ3fȞ={tTaj~F" @5 0)@wPԺ+WvITT 2DܡyLwrP}7oޔx4GISuʁ #RKZ ].]*AzE{׮P jՒ^z[vvlڴI'M'O,aaaz>}+7@@(-  )?ѣjU~ڣݻwF:*,!111zDZϴ[nRF*O  x7F@\N:9l2=bTm4l0wX H_zZΞ=+k֬I3g~#>>!`J6v@rre-~~~zJlAP  #be״@iiirJ QrfL*BG(K ((H~޽{uҴW^:Q>eVBu@)rBq ͕͛7W_}% .]8:CZQZ?|:i6zGD2Unb cH:ƙZ@(ÇurT m׮DEEM=ԩS283 (5So \~]o߾]z)4ӧKZg 0廈@|QN@FzLWP@ʒMJJ#Fj)@* xyya0׮]7ի7[4Uy #Jݹwi @ /^,ׯ.]ѣdS; 0ԝzKdݺuzzÇ%<<\ϐڵԨQÝJ[@$J @RSShQ3FF)7`IJD)p}ާFFGGEmfO~D @9H@<[ƍa=~2tP=z4$$ijah=v QjD@ǎӣLW\gPDDDi֭U! `7D@78pZfyurtF)8WDs&Pv=j]wUb@Sة@DQS&Mjj}BB4oܕ&6@.fV۟'پ}?{l=%?22Rk@02j\ veݹsQG4]ci.&RAj[i\\t]|١oKr@OgK &8r䈞Z6urԩS" 'Pvm0`]rE֯_/-I&IuҴGRV- @}SO=&-WDyӧjFիW(S5=l\ @HV@\Y:9|r=vec W5b4kÇQWi-O , L ̔kɓ'gO?Tڶm`@JxEf̘!wIP ISgÆ K-@#JH .!)jh^f͚.A @(-ޅgd7orz6m{L'M(wy'v@j`Di5R4 @ :uJ.]oYfIrj@@jUS*i:e IS޸wO )wZZ ++KԚ _222tt2~x]G@ZWg$&&?|/,?//"! P FVK@#g%I7ڥKׯxyvV@+Pn]yٳf3gf#86(jCpYMW@=e˖*!ݻw4n=L@@\M6^zIRRR&P/]!*iڦMrI (6s ܸqC6lؠG۷O;\U`3R 8p@'MW^-M4 Çw]x@(FŠ s%Kbѣ걏sV@0 noܹSk׮Ҿ}{ Txx 9@`D@*pyYbZ55j4oܡqP8Oγf}ZoȥKDm6- `fFpQYQWMiS?SRF @Y(u<"@IzJaF)?$ {(u~ K?~\]ls=zja$ %#pM/Dݫk֬VZ餩|Ӹqc@L 8Xʕ+K7ey|zg$@@=̞=[[:u>>]s &` :@W8uꔨiK,z#FJā&` ;@@ ##C֯_jmv~@.` ` &D'%111zjّ#GFGfXu 5#v$JݮKi+p9QkZJj-S5ҴcǎkB@3 (5So+ @={董j.]]/^^n*|XFP[5<҄F# Q(iA,p=rtŊz(2dSTe (-ۈ3@3RSS2IrQAEFFJppgj@z_8RzGUf?j(U˖-u! AYf/ѣG(_z:~DD1BZnm(@@ 0 t2tҥo>}zY&[GSQ)=M;@^IUV=ܣGѦwu@#HzdhpǏuGUEzÇK@@;46  (Φ `W>Lz!42dԩSec&0@UHJO P1 E54""BoU8p ޻F?P@MARdԨQuViժ [C  TL 00PLoПմ&MX8QD'wUXӧ̘1Cz)g2_w1  {u(;wIST(pWj@zz_=n&uGMmƤ6fRYKi x;ޜ@GWV҃ x 4߿9"@*$ qq2x+Wdڵzj/#GԻ}5H9@@@toooyիgɲeW_}iϞ=VZī Q hA7)jh޽f͚i"&`D:P@;\xQHP#M=*jT T.]P:E  QZy;D78}tuJTTAZ~}7j%MA\SDk Q!PW^-*i6KU[Z۔pã-N} 2YYYb <<\222d/, 4޽* PQp9 .ѫW]y.+!  @ֹsd͚5oӧEe;vZ%\'fN4yl޼Y.]**):p@ }'ܧ6sN N8!R Su HHJJSWX?_ "uP[D@W8tN%5j7>|8\È ` t! @/_֋jjͨQd֭ҪU/ @@8:͜9SvܩOtMtTmZ~}s P#JKp@^^ѣһwoQ=FN@%R{IR @Y[Q[lΝ;뤩 je:/RcZRRRjQZ?gQ s   }۵kdƍ:iF̈^z:]0nݺ%#Gd!uB@!@ԉ PGGi֭s9 zo#\*-+Wp t=~2afXF@@>~'||{Z4,,L?>w!y(>8T믿Sz:uS:X@#Jw `&(>Lz!=5`$V QZ O!@Ξ=D_dԬYS'GyiҤI j@ QJ@qlٲE'Mm&ݺu0;5 M6ѣ{!C(>f@@@j׮-ԷL=tѢE+O?j15\_GDK !!A7o u   @95j$ƍӷSNjkdzMvڕ$NAG 0ԑԅn޼Q;vȀt'0q@Q @  #W#M(ӈiѢ#(Ce2.,/+VH۶mLϗ;ih?   P!ۋ͘1Cvޭ=zߵTtСҰa  `?V%%!6/_?X???ٺulܸQ'JIMW:@IDAT@@p@ΝwߕG믿.jSܐ=tz3'Fx#J=i8yyy7f^zɴiDYF y   `ZjI޽-;;[6mڤGN AXd^A#jѥKJfQ5CÁ #Xԁ `65/&&Fo64hN> f1[giQj"P'pYnNDȑ#}gJ( @@@u֕{NΜ9#k֬ѳΞ=+Æ #F?\ 0 ;wQhnQ5CM@@Y(u<"Q %%EO_r?22RkڦM36p).N>իj:ѣ/ 4e @%HVK@08ѦwuF} @%h\ կz3tYx$$$Ȅ $ !  e ӟȑ#oʷ~+]vuN:>x`DGt3{jN:ѣgwDO@;@ 0ԤG .)#[n Q? {wC??"1?.:tw}5Ex“QIM[R@-=gyuֲgYb <$[:B-&Kl… Eˁ ~ZIIIzeˤ]v2~xٲeܼy5jȎ;EҹsgoAQaNsCƍi&=zT"2d=裏Gi F/e#Jը߾}aÆn@@p dڵzj9zFvҥ ˯~+ pSQ)=M;B 11QL Tm{OHE@c4@5zPu͚5㋙- @m۶+x = ԣK&QxROmjJ߇~וy/R:*Qkv4 g (US T1i$VZz]?/;ȳ>+j:j@>^U;[ѣԨQKy @P̨/ɓoMi f~Ni~5?gΜGꤪ^ˁ 0z8M@MG/ Mh{|wtR}urTX`{*@p{5tΜ9:Q6rR3+8@@9>>>zMR.iiWw QꎽJ*+L8Qݢѫ?Dz}ڵzJ1B?Vq  m۶?0^xQԨ]v7O& B@}@zJ& gZ.7h@V^-+W _w]USyCW/ "/xyyɵk$%%E+X@@p@MJ\@M39sK{=ƲI.]^zIoEI~HZ"q@C''N5T|@@%@YkZҥ;rbۡvTkL0AR@(^@%GH .x@@1Lw3'|"Ndhi;vLN5@<^UVҰaC@@9(u;L@r _~Yӥ$j^ffdM%\@.#$@@B]-0@q_|DEE稍'ԩ7PkJF@i׮׿?  PѣSN%  8Fq ۷O}QַMʽ+m۶ }_=V}&m%a#   (5Fjƍr&/!   YD{@@@@@.ldF A@@@@3 (5s;    ED])@@@@,@̽G     `va@@@@0R3#    ]HڅB@@@@@^*ׯ{3s[@B@}ڴiҤIg 999oKzz+C  .&+"#;op?5h,_~L8i1Pq|w.ޅg@3 X~w#JUcԈ^x"v@ AҥKpו6l+u .$p)Pll+c@ߝY}I     `v@@@@@0Rs#    H"@@@@@$JD    v QjD@@@@@s (5w=    AD)@@@@-@G     `v@@@@@0Rs#    H"@@@@@$JD    v QjD@@@@@s (5w=    AD)@@@@-@G     `v@@@@@0Rs#    H"@@@@@$JD    v QjD@@@@@s (5w=    AD)@@@@-@G     `v@@@@@0'z dIK}ߢ   >xI.A  ,@ԓ{ ۞{e$1kt Y=M@0@, jǘI 7@p@&'k"Hԕ"M[Q2"֟ZD w@N 7[/Jx+iīA3fXع3SSnjkJZ6#vTa|@@ ͒=s]8(ʓ)M?I lIMOyD{:"uRNCipwSicCEN:H)u5CwD/׷/iW[5#1ʩ(4]Ff|2mP\uaҴe ҩK_"9iUDIV@ޛ{RzK6P{-UۢCOwh)rTײTt;29hq?|8~[ϕs'JcsxX9+/c muƏ֟ZlO1  =sy罵b|-/P?5J>Ԭ2oZ%"OϾ"im\#S>h ccn:wM )υ}vwfjr`q| 7O1w \ȕm*sf:F'[,˔59 AUcdev7TC&vR_.22 X T731FFO/{߬)FS%1-`-LTm.??]7Hq](UTP '1XT&SWW?X]@ [ޖY ~m>s,ϭFL>gl8?"wi$JTA9]ڗYrh9v;M7dA̹r׫fE>)1E Wz7?/9U&0r")Q z `V$7j)$$iqVݻxV = _)LUKLp~^7~_i&,׼6oLFI YgA՟q<6oR%Y .g}M;5潯e$gƲ^u?xܼ%}1>clSrD%r..7u̼q燎7xmjԩ6Y㬯/=xn%U+oŻgFl3K.0}sV{=TPq>_U,W-_kIK,?W= Y'68jHWËysms{fI%cQf2bfOUP>U3oSQJkzpNȲZzʚ:[% ٲ7U:53K3xpKs~6٥~ҐM39zRf_{7Wͅsy*;M02bY‹eƭgI2zK6QjM~?hq#L{QƏ/>;Djx7 \h[ Qiͫ4Xt# JpJ/R'H+=:H>crb\7[Y`IA$餹Ѳ;1w?QU?l$ڀ@6hqvX]~emk.l4-npkw%tXk B~ddj&".M;wL2$Ir?{sUJ w,uÓa@ ީ/zwݺ{j$Yk*-:խsg}./rZb *ަŽBFb^* O13Lc^h?nUJ: +t&N{/: zkځ \"U:F3?RvS|6?urE'1OF̿mmӶkf}l;Bհ8ks**-E4 8F{Sڷa}b1k%Ͷg8 1{Q2] ~QfKhqp9?\aW .ezr}9S9{=>To@/3 ~rty#z)Jq2StfM}ߵfzX,Uő\PJզ@ǣZ/O>ykz.hMU{Yð=B؅ 0<׽PJszǾ֣YW[Nx(K vz|xTY3ݕrYcfWVfio:ۼ7W"VLL?;:ߨ5o&1C4LGLy߬8g}{VMPPK|單̥JZ(X̽qsbZ7({4yEz7b؉L<7\5chEҪ …qׯoFҘQϽpTy)v-n^2]e3%#O{^iˆa6<״Eg`^hR6o嫸&3Ov>3,|ǝnYnF7 CߨE4I@ ʏb]LrVO{$[CƝϪ)kR WBjmԤ~x2ڪ__'H^ؚGۗ̇¨O֕{ FYo5'MT7xΕXӚҡڃVI{]]{fP!&v>ЃukDƾ+_B՛FЭi5/;bj$V}KyId_t^J5OOҦczq } tҕwY"=MO:JV3 46aq8"Wn@OFRkz01 Qs@`" A쎦[mPڊ~Mј;jm7?y_Zo. 1uZ%`a%=+OkwͮݥL-> D PNw'ض+ޅtx5w[wH;;0-[5 q޼ܵI=1)Y{o_P{KoܥՎ^'ť %zX+ԃ&9NfV/NM\] Hٽ256iFkP7_LQXs++d\ٗ;BH5ڬ`.Uj)s>,k\Zuik{Lj툡m19kXOd9]9̩\sؽ럜݆<}Fp/-]7*S.awo?j[]nNxu4_=5գJKpZo#WUi;jib/ݝGǓ`SV^zN+eN?UN'WyKWg:? k(m᷂üz}gn)#oMt̓Ua+ֺ$>G5 l` \"k 82qy@`iY>7'x30O+o~PSca4ڻabs2==crѩƃFR+(Cݝ7֙lg~kzcUa]%լ?y OTNr &, 0 "mzz}zUjo]ݷ7uu~|jjMm:7#X]/ا?Lw{,˜%7($( =m^`î pk.tbc|HE8jVOw N.ܡT}g;o)1Js4u-&wk˶9 7ڄ)!vN ya!ɕd 5@W T;YS\ a\Yv0 .p= Z~KwQ=^|.[I3t3?f3kӤ&μnn(7z@}bwbOyKwhϦŶVTrq__q (ҨzK}KC\ln.n:s Ρjowkxm\@` {bp׿#2oS7ڸͷ]]?zYvqU^7ڢwgW7o:i^]'ۤ7p߷ ӏ%oS.J~b=Ъ:9Mڣ8>xh~G*ڛPO>gnMݱiI`xj<ӧNIuǟoj*bpy+^~HNE:sͱQ5L]UoL#jCixpڤ1Մ>+]MyԜ C95Uka[+M/!N/wbǞF\BB{OR%Pϛ@R{.>3o@=o-Y{%B7 {/JY0)S6wkǗ8 %;!ֽٟh{(5Z1=yToӥVȷ9o6xܼhj1VϒBZk߭[ާWGqmey_}{U9m/6Ӧޫ>⵺d|>&cFnjK=TL=NfkђeZ45Ma=u7;e߼Yk=!_ޥ[j=gNJ- h:NY7_ֽ; sYo)>Sm}_nPÏdzʦ7Nי"\yY@ "0 &_eU;жU|[TksG_lWybZiw׻]߱ʼ2)"7O7:K e4Jm\NsV>zݶw+hY?}\qjvR͞+ϢE;j <.gm< |CY, hUx3O)w̵sNUª}Hwo}aLaxjCc>*_ `|iqq8̗gx"+/ÐwwrF-g[$y_xߚ5k'A*%ս?߃Lzu:h.tBy_ =ezSYF_~1ߑRot޻{IűrOmMo룗_1Tp7-쬏r^2xGˢMXZno%uV_YYY#Ap51sؾ78P*\Տ1կ~/px|UվC}eE[;8YY"J-VM 94FW`-"Ʈ1(`lG2[R#-߶ TG쓆C/jS|ˉ߾:{/3o/7x}יSަC1 2 ұV{d/ǻc)Ѓ q0/{x̐^Uc, _ T|G7eÑك  k/G}qX6;d0kvWǒs ZWݨ+bx*pCniZijw/TCMϿ&*TUZQ]s“!̂hNqaz޿QnJ s_W;Osj@#0 Lu #K'l <[ޥklY6^,mW!u+ "3fn}a1Tj3t>l+ Bo t4CM`YjSyUjdƲ,Phn4W-^g?ih-aʁr&GQPp8;=gwr䫤Z:: @սW/c敨ցt{r DzORm19Tu䤺Z'CzTmUV^sf޾:Too_)WX^ ~X-*oSyZrG%mԖQ6YEQz/mORhUaL-kۣP̈́6+0Dˊ#,k"g 0AxOQIѣa||>1zS[mѦ<ya}U|WU;{?d[ y?ϳ-U6 ጼMj>Ra^iZ-kSCGYOO<裏/Ѫs|,δ!(37LkYk}!yԬ31C0p >\O~?~ 8: w歵SL'uŜ9HwFqlљsy+e֬9uWDžV9Ϸi4sv+[,<3r(wwu|1kߴ{rll[,9|+_1giÆ "U HcǼQoΝ4\|yw˪{iWQVL慈(ɚ9Yq͌޽/|4͜1C1[ c2*v:D539+3 jB@`HYZh~hFfգ}UIxNz+#s4v #/01EٹfEsq#`&w mPGbc'`h#    P:E@@@@@@`h( ~@@@@uJGH     ]ď    .@C @@@@@H7l oүJ-_s8    !@Cn~\x1 q@@@@tep     @ 0Gi B@@@@ P0j"B@@@@d4YKt!    @h(M5!    @ P%C@@@@@ a4&@@@@@ Yh(M֒!]     0JFMD     4&kɐ.@@@@H &"@@@@HVJdH    $L҄Q    $ Z2 @@@@&@Ci¨@@@@Ud-҅     4aD    *b%K.??&kI Ξ=/|WrH L:UUUU صk`yveL@` ؟'b|{ŋ'9FƱ@AAF9xgeU, &O{׽$9I d (xv6c    )(SEb@@@@@`$h( UD@@@@1%@C*.    #!@CH&    )JTqX@@@@ JGB0@@@@@`L P:"    H$uC}ݧΑ ^۷o3 j,iDXݫg}6ӓo|Jp&'? g @Dq"D܉UD;q. VOO8/[o8:( <_JgΜ|p}8rB@]gK+b̉( @3    $^ě#    $ IV $@@@@/@Ci͉@@@@L$+    4Ĉ    I&@CiA@@@@ PxsbD@@@@$4     @h(M91"    @ PdBr@@@@@ 4&ޜ@@@@@ h(M!9     xJoN     d4&Y@@@@H 7'F@@@@H2J@H    $^ě#    $ IV $@@@@/@Ci͉@@@@L$+    4Ĉ    I&@CiA@@@@ PxsbD@@@@$4     @h(M91"    @ PdBr@@@@@ 4&ޜ@@@@@ h(M!9     xJoN     d4&Y@@@@H 7'F@@@@H2J@H    $^ě#    $ IV $@@@@/@Ci͉@@@@L$+    4Ę`GyDiii6m7Pff}n@ƣsE} ?&MǬ'@<;B$ q  vttS__}uV@Y4e;o_z I@@@ p³sI5z='J //'R|V/+VD:>@-`9і hُ ΣO"@Ci1k߰o~s@Xn6F<}ҥ@HHh P:%@ #3sLzDa' PİF0|SJ\ $LgQQ PCWӟt>^gBC&@=10:? /s)YJG֗ГD Rz$I @` tMa9bC ;@@ xvNB!I 4D6ZzлgJx@+iRF0&g 'SiP:5V3&D#I//2 6mN8J'\O Zw[  H D'l@NSƚ cH=|3dF.DA 1q  $IS$dh(t{'zN9+ 0yJ'O*#&BG@Ə,h(Wa@zB$ zbL:O}j $" !CM,J'VyOZ=|&Me˖Mx @FN'': #L  02<;+& _Fp>փ+{@/宻:̰@@Ygd.6)#8a#l@IDATz{߫%K$[H 8XzY L'B)H4FRa߸xu @rlذ!9B*@@!<4. EH@@@@@ ^Jz@@@@4"$      r=    yJ|@@@@Wx@@@@Ƽ c    +@Ci\    c^1_d@@@@H7}{z{315c@Ng%@{{~a|dĀ!ӣ}k|^aȥ$RggJ;qիYBm۶h&HG}_o͛7/iDB@H_Wu5hÆ ƐcH?;P:a ԩSd-\0FL'o=b0cM`ҤIz߯%"~7rLv<;߲%gG\      Q!q    JOY@@@@ C2@@@@?4$'     0DJe     0~h(?eIN@@@@@`4@@@@@`P:~ʒ     h("!    t%9A@@@@! P:D8.C@@@@#@C)Kr    Ctp\    GS@@@@(@C @@@@Ə ,      Q!q    JOY@@@@ C2@@@@?4$'     0DJe     0~h(?eIN@@@@@`4@@@@@`P:~ʒ     h("!    H?Y!' 0:.G'mfF@YCmVM3c@@d4J4 0AԴkr[=ʥt>D]ڷvۛӂF=u_69D@`\hUkoJ'sݭW-Pvyp4X @.uӜtI=t9;ÿ-.sNgOwϏXْ}FU@`La%MNQjzSSUOLe Э++;2͖~mٮefyĉC:yF{nvЪ`_#E~q" W@0HvGv̜)=W6-p$|WG)w+m\eUJ˕=I'ЦٮSuI]47\x:̗hWwaQQgap~#lR^oICKZUYzG#—*;Y e5=jOx}}Si(Ļ-/4&m5-PV@F\g~yvVǫzdr2'U]QĞȣ]A~7Q1R[Yxɓ*7j Hy"9}m$ ghg5ui׫C Z6.mϟ졞jnW}}NA? 5fCF^`Q+ɆzxGFR7bmޱ& -CBAı֥9z#izv#nM0%%[>OGC:h@WgD%Tkż5Q%$t}>Lf0,Cx quRs>vo 4JXﾫӿ>lzz]}>u.:{^3s*-MϺVX~>8Y:v07e(7w8_Góh3?/ۼϵG>Ku\8vT˞w'_٤ԹzB7Ohme~q^1]7t_Pev߽9fvK*(|I[WlWOkSN-[*&}!~s:k:gƔκF^9-tE cL쟟(%un PGk)6[9tu/TQ;L3ZKGU+z޲O:]f-[0t17wt}Z_]Buy"k}W]\=R_uٯ:gVG m>{:N/z{L{Q_-X*sw'6MOc/]ۯU,xێwo>ZWO׎뉒.pc^RMKzw3w4>oA!]mjxIo!ХF:كP\;t꼰zTZCf^+ϜNyY?iGw}VyDkb}q{mf e\zJO׺aeNir|-=mzSLby3D-ҐEY~iitF/{U^:+Sr>r]g "@ƞC{vVufO[^jzvެ?ghϭzHE[(A5/AưtR_mm n_E|?YO~\gA#tܬ՞rgz;r]׻;ry(cKۑoh?=>jW#-[+zg.7'tj+]K8\v)?k ׮g¨unP#JWlw\w!GP}h{}N:6#a&xwC=X.[l޽;K|sV,lݺWVV˩C>*wg$z}+qnV8_gyX͆v/[}?rYE+|E^W`˯Ugy|vpsݱRL\8OQ?3uc: ds҂XaۈCb_II+^_qISlS~H1}ՅQ U*EHgabp(ЀI+.73!RGT-kqLK6Ysj5C;5GSZqBהN =YPBқguk=އte>5W5ԇ:AT_f6ugڪOّv3?WWX?/z7PgM X:{άy?~XZLKCFV=W_uTu;)׋ ⫯dnV͎4E3W05;Ljcޡ7FXWt'BW:֮vlj9h q¦&6[ xp=l x޿myvFnR)UO8h]_}~#&)i"(La X?_mOCZvs576*壶9JG?XW'5FMpk]7፤ x ꊾ^s>vFyZkzO{ig55o;ޮ1uV]eAXXf>QPcmd$CK}^2/}mfʃ(H+Jџ]Hj) 4s)K~hmn$5Oa?HZTVc?vP\ tt&ޘ=@#$] 0n[0/7Y_u=c5K4wf&]Tܦg[hvm߰24|yZ+/zL..)׶=q\_H_T,ӋAEaX<]eP,vQi\Յ 9xjy=|5P7=q,{/6=w7zLe*+) ˛wyJ7g_Mv'Jl۶vzպ=7)LoVSviټLJ.rv!W@0Ô`x \H`D`9y3mgϿgHo:{(|*@<#U_W]¦wցѮ /wMg 9>t1e Ѥݴ3Ȫ7p)E>w⮧=E):) {3y(lڧ/2|`z#23$4l}BWj.W+!pOWXgxY?;{Lrc_AA5Up2.㺧 o#_;RYg(.tޓYCKC!eC'COPF{b 0j\i/T͐W#[EwZcܵM-r{H?^󎽣˘z.WPQ7ߍzd0.>3)3/K &sþ)ԑo+?l1Avd,&3lMæB3av)ۧd_uB?wkﷶ I1]_yO^1Zyw f Ǒ##QfU-j9v nXOVt)G9rLb'꺠Sg2k¦q ѡڃΡf]}.QUsZc{ᗛaahʕP)dmt]9Ǟ՘m~`]2 G_k}'g}CaYkaF05K*ř7 [Ҟ [ͮJ[̃?qk]tywBNt N_`/-k x9Dl j,;tRf>O5#%0_Vi邖hTfej`w𷳏ipwpeZC_IW]俛hz;L֡Ǖ+i(M3$LG7+J\o] eۓ2{;]j;+(W~l@CkoGz᯴nn8©gz0p-gjb {4ӳ7ju\ib ޱB?Їl~kFw>%+_~B UV[_юyhV{(Y!ѯMGP_u]0C׏~?K5>Ҳ_ݧtS$Гljԧ?|3y#oi 3:4fvvg)#W lF}-tl )}f;[V |axJj͹t{N6Sڕ;+[|vsg9iZGx2I#hkT#"r"@,tyv4^%^]kk$'2ܺmȽc%QZ;G~oq kۈDD$"܎ W#O70 ' t(h{~ξ B[/;2÷\A;+:tSBu -*d~ի'2+q6y^̇7_?B_o>Lg~~.nSo7/2/r~Gz^UѶ{}3ޙ<i'KdMvc!pq $@K3t=*S[iuݢ[_]8[g.齹.RզپSmghzg]urGj=שɎ&:f~ٶAK+dשƃFRkm^yf^NWWvA+IÃv8뫰:R3iܹVgrr;@'seϳ_{Z*^=?-߿.4 "lRn?}-noE͎|Un7#c|w`c@J$)π&>,X ڝOչ1o[}  Ny ui)Z\eKg+^+o]4hŝfEo;{B=Y {P@вϮ m5-izsGbVOw ϊSrݟ )":Nc|;*5 {{[M7ͽūo~JyQZNթU>0ݞ@` Lv}߼~q?_z c^i F_-?%[6=~Yi|]c ڸYٳI |usm-s9g 2Ž>YUoܣ=4ʭ騞9gt}8ʢLie+\kzOM{:xPwe;֩) B_gk\7 0\<;4P9 sYw&OŚo¹zJ,Ε}ϏqV[Vk l>7lUoW?lD៟0 Cys}Y`t]%4 ~꾕 c P:Oo+ 8KN\4yL'7Yޏv LN}U j vBjJǵk<{6<'mPR4> | >ҶtCm:N'=Ey*ա{tg-0)_8ݤ:jl}Q [M| ᘭiQ}/7=nf/HѶ{o ckAۛjMf? tBZNʙP>9u2#N; mVаOMCK|A{ۥll&o GiI=o-Y{4.;XC "ӡݟsǎj8hqW;VGmg~޻T^u^;M=QwܪzLdP/+ue'uBo.ӻtl-YQa<ywևtG'~Gqme!:#usz3#j :S϶mNשjh^~њӺwhmPn1tbyI2CW쵝ua=W/t4K~f]fqQa=K6{<i/)P;Ny^P7y\%ݪ}O6f1R6[jB'g1a 0xvWDRӺ֤޺W&^KOtL:gNJ-rU7KF_ZFo|JCe9޴x}Eme-ް<-77,kl{ˮy\x82oku_þk *o=V1t&_X|K=k/%v_p Ɓ=>1_7ƛwwrFcш8#[cwٷHw 3<":*ϭIoAWTy)>վ - ;::'} }M-;,/k<./7uf?uu~1ߑh~*sa6W,跭﬏RFd>_[62܂+#y&eC9vD[%<;G֏U>~$U'z|EC|gނP?FFeoluR{ s[4p{@Fٙ Kr t3c[pG>Zrm"xRvmݬ[K2zW +jy=Y˷T8Qeye_Ly{gցvq$}k*mp.tԹ9Lt^z{ٟ-#/c^\TcGu|S @wğP!PsٓOr ^w6o6\j!OCC/1wJ׫81GoD nTv1[\nX<;j/хa|w4;^m ,JZBU1fDWrpgH' bYoi,Tmsڐx`&ݱ=4)&]>mZ5$Бͷ&vM]wTLzmNf;=gwjOJ*)-H %GH@`\ -D$d[<(Cү^mai;#c9jVMQr3nNUJTLOֺ<ۋspjoH_O޾QDMG4ODGΏ]cƹYuu]ޫk&CR[(i(,PmK,ތMj>RhAY߲~VD[$bXr:[jUVo7tm\֛EƝ΃/R9h7xߐsףa_Nz~O}nKL/*V 靗7PzyUYZ ?_{f8fs޴y,C~Ԭhu]~PN7/;Meյ5Y|@#mwa}ÑjP/3j|_B !yN9&[LV7ouqt-7֛yZ'Pcc}$N%IW TFF:ޠ~ޫ5koOH_W4k,mذ!! w$W=j;ըߚ Njrf-:gz=^*?+yY3I+} [SODӯBs23/ic9gzG|5k23}UuruҦ10;.X\2M3gP PH[鸠3fFuw{,ovpqXqO9Lyyiwh~T}sf?jyӪc064A6p(1-qiv>ԤcZLHtĘsnybL!0]j:A3g^٦Qa%!/+{ۀs۾TRHZoff.[W6:N̜\ N+%]Ygb{HzW)5? ff 3/i+󙝕ZfdfدH3㬯Ms| :o&'De5@&0{!!7n,Yb(W5305AP:̠ [󗬏!qDo qN6XC0W( I)HR J &QB%˴xGVyjoӽot덦y!kΙ-|%hو@ W ':@pp/`c P:|B8ݳZU%ֶf9X/8xP_s93Ra:ךv1XܼYEaa$@"Cq#@C)J2ү@JVoc~N ӣ!u߲  @H*d $^{ěcR $}(2Lb&@K{Ή.B@Q*K4! 0q8eMNb`@@@@4NR'         LDJ'bg@@@@pP`@@@@& 3    8h(up    Q҉X@@@@4:8@@@@@(@CD,u    Jl     Dt":yF@@@@ 6@@@@@`" P:K<#    CR     0h(N@@@@@!@C @@@@4NR'         LDJ'bg@@@@p8@ F3gΨX1^i h}{뮻-!SN֭[.iH@K`׮]*//Ɓ¸?;P:{d2?N 0,%%%*(( yf]~!+ƹw]{gkk>o~:qDp OѲ>Mn! SM@@@H.UVK/ >c[ <_O4I+FUQ?03gTff{7    G?ouocXCC *@Ci|^^"lҥ@@@ӧO>ξ-gE"c'LLJܯڈSx    .`=G[u]ɓ'wX$-o1bʬ=    @l'd,/Vmf: J O)V84&qY[N2şB'M"i 1 X]vՓ[/^ nGiL Sj}9}lAp>LJ2?iICINO~Qq@G>OhѢEǵ 0Nh(M₵)4iW5  c]zYaiJCi$! p r-tD '@CiHxbYv1?iICY[o8ު!q,  H X󔦤n(Ƹ I^Vk$O)C@``?^s/V=gaʂ @`%KTc\$/|PmmmIJ @l) -B@/`Mon\B$/=ǂ xpSj=XCX@@^dMsǂD4 @@`2?Q0   BA`q* /I7%@@_ @!`S:eʔO`@@FQQ'jٻ6;__vb\4]'ŢMJS$Ҥĥ !U}i".Ɋۤw}pE(O:bE,[:(--q 6`nTޞIǶ,yHsf9gfPUڤI꧀(@ P@~ 4sC Pr u]7%BR(@ P->>(@ P +J?K/ܹs ,(@ P(0Q:sK P(}cОvo <,(@ P(0&X P&7 | _Yg)@ P(@`Gi3H$@..\l۠2U|G"9x2 Q^u}.Z Wu'OB`LȲ4MW_}^{-,YfJN B}ݗq@iqu P`Xg0zA 0fώ4^{5#<_vHL9YQd!_w}n5Fgi.vnۃe%˅SG_s|+ew.rF\2(@ P OG=ر?!mn@cɂ s1]V\U,CTͣh|+iFV-Mau"m`SDQ.)?}ڃ+I7z'mg~צܹSݻw=A;U,u9EcqzqL |8Fhd?R$+B@r|mIwe=#okL+- d+Pms!r.0ZvsLB*/҇DۦTa$nH:L^Z$yzq0ɧoZ^NC'̥$#`ڼJ4(G]F{5٧H*-`hR(yt{N@fO}`8¾[m0'H-_^JnXԙ/3Sޓp pNy6]z͗xc(j[{̷Goe; !# \" Im5ㅉt tirW;GyʹITv[-V2!&+>YPz޲n :ܖ3*kt;jqc:58N=Y+@@8M1Eh1CMPFSܒ|"h\6SUMc~7#mz[4k]j=ż_mf2AO^g[ۉ"U>Tj.Gy yaw0L&zG[^7[2܄c! s4vvA8x.ۅ'%X4KmzF8 Ѣ(_90ukS%Qvoea&;1O,qR{?u;فNM3`z6iG=:#VӦ',`foeMgOJP-wܦ>MގNͺ];aTw?l//7coNQ^ ŗtpG|)2~&_hLDxFciLg,gm>nL5~8O0p|+rd&Ř\"sx ^fuz6 cc-R4c2aS'WrPve\(0ȳ꥖B}bSmnq#_k q|Nl*)_G֢0Q=vX㘞2%[ڶv9tіg> P Ncslء^cζe]| &ݴ5v)wh+7.z_ jjv`S<onمxaquRWE8x$7ivqv؉,bh.E3Qa3_jș:7HV3]QaCTcNn9kFֻ#qZ5:[Hc`GiԷUsW%^=+V@^MbM6}Smf6oތ|v\P[, گ#3$g}_Zb_Ljr nIJ4\˖݂j%bX'vVˍF 6sLxU{ U6l#&:U'[[ y-k@k @k#.#v=NӸzr](@ L2S8d#eI QnCWjх٫MEw̋Ƽ7&c_k.[9Xs@ls•8Tw.o a zy7yy Տǡ :SRi7.vׯ6εf9dACS+rF9zy4>Y˒^+̻j7."yY6blV^/s3Y7Y{| eza~WF]I-_(0*qieG.. !;r_| ܾrrzA1x'ЪdQ>"BP154w/$ǰ%çb+f4mFzۈkN/ .p5/d+*jR%q$ybecvٷ?^%Y aOj:$ kţkbyT`DZ2s*`dv$?!g5oCbf,ZӪl n,ĖCX3!`BپCϡ+8M^M+Qrd~v, Ǭy xMٍq(ernD⒤XWΧ5jnʹAwYR|ܭ]97RY%ݾr1S5jG>wWAr'{wh4o9I[e l[bW;Kssxqwǩ7dyu9~~u*xdhڴxHO<-v]Fؗ|NSkش>x 5XwY){ufẻn'UqNՎk?>[LH&q+C8>p=n/]?zȑ۝ζ;tvȫë'_(3j>]]P*uȓqJMF|1ɘYgzqR3oU-oÊGȣFПΝY֤'bJuXUؗo2964l]rP{${/S_+H6 /GAgS?}\$|]jkʮg)@ L@ܨ(GRȞΉXy|/;0Ǿf>z~5r:IP h=tSvF1|Ђ+oɹS(ˉ OyJU}T<'4~,Wp֣IYd׵9u(H?oVݽJC?R:Jz`6W%﬏e+rw"EV4dE.S {r D P`&O8xIk5dDnUY~^ Z'݉ w9{21 ,>ԷeVaHD=ؤq;vWm7bF LD{s]y64m_0i~* M =|uŐI~)j3]2 =oc1K#z.;Ion|@^3wћn#ȇ!U h+WoXdO;nXons&D`=YN:|yb,:f1$;W]:g2yA𢡄QTU46?V \rly{3E/xoXOMh_F :4RmzHtM K~S^4{% u J/[r.ٝ oBX7V6&%5Y Pv,h[k%4E`WVi3Uwl]֠TL4˻N][d<~Sult̸sHl*g@ba cK~Z=*:Eh |rU+MlT}߼D^ilZT T/Iª5Ss`.g#oȎe9zȫL3:{|)q5r6SRqk!!rzrO Uq%Jv)z)3 rsi˞"|}e^m*-+}-k\:o3jU峒>sW̫dL]͇FV,Sr$g[fjfl4:I햤>z!HNbs"کlӿik˹Rn{ QWD΢rTVYHSh_fz̋PK8x.7v_-?is E|y^Ś9MX}{vsƴcbdPOq{:K<7LpnCHStʻvxl֋,]*,qq~N33[>N3ǾPҺԞ~KRKǞ]LvrK;YlmY-ZW m3z5JoůuI9{0ԎgcbW-6JM aǣO5E5ط}e,?8v𑫡WOk5~?ULqVG^b N3ᙰU-JGi&G[q0q129 P9E8x.weۆv|U߃ _T?o 1͞fL}x/<{B,܃F_?Şґ벣tuԯ_m-ѫGG_Ol|Q3cg0rͶa6ķ [@>,o P(W{'C=4yj؄)\Fu%wl|Szk ON7cp4}O4V4Ύ E[ky pBޜey_`|8낑Y]@FN{"_!Y-jYuM"Fk[@D !:'!-W}jht 1%bGF@KO͡k˺jqiXvv)ݛ1ymR|*NF+{:0${vlM^5" c+me?[aٿZ!chPn'-p@,꜖ ]aKm2w5zh$ ujS uPW@gaMѧ%1_mzAS &}˟p\]Z)EE_eʃ#,Pt zEG9D Ԛ/-o]S[7W} tDma)#dMc=7c^;6h:DȿI{l$(ԶsV,Ȳ]UW*JŒ..)-?&T _NKe;U뮆]ޣ^^FkI0 ;R6:jc)=1YHymnt5ReOO<<(҄ 49Ro%EE]BGpD{l%)|_ƒx<ܑD9nn@18*'j,M:Цtk-)s22FlNhdG.*,|b*πe'z{M}qR՝U|W;|)'k2:CfgL 휲}d)vHL3Qξ]M<&&k4} RŴ@ĭM$'}}mH))V^+S:4zq:GH v68_| Ig#dy^_l52[[kh,ewCdT9vm" ŷn,fwmg8yy{%ڭ<޼Ɋ/|% kYG' rT5w:C^7/]Q˷Q߁Ez\A}[*h(>RԶ<>'ll!d4g[cGVyicd^nb:4x3442(C2JoP'!_Ry |YPFSjb{K{|d驎 >m/؟Y(@ E8x˺]M<&&"k1D%LǡT1m11a2ٱkg݇//WGzXLҮMܪC5ӯO` >ƗyX 0܊|ojdֿ:> X:|c=cK.f]MIn}7ȧ )ڀc!zZݒbr[ *gҜʕ+Z. slQ]'o'm-ELM(^8-cCaaKwfm 1X+_ܩģh,7=&%$Z<)veG%?ҍD6DgS, T^9M-IG?6W]lӛ %o[wȋ_:2)2;|zpU|AؼYsCErH*XSn7y';rX+J|?8|2&*K~ߚh昨y&Jo;.2˃vq|>b!!O*]A RĶwUhHRpچ> Guqf(0T4/2DgK]!R1'󌃙 d˜G>wCYYt8prN|{Wz3K䞋g\˯l㚥v֯ "cƬYt+$H+wm(KP^ CPX$.+$5w̛?߉Ҏ+Rq\`׮]7ood4RNOfM C! ,i02xQT濸xf]z)S"W!yEa=#Hs(79P?u{F:ҙs1g<6'KQG`?zRN,R-G9'Ud DJyR~ԓŴacb/Nts:S){{ ! Ds`Q(b|Nyn1J#i&lJ\.S*]._YU-roNU|7UXn P9(ByJmFd,XT\l"._$eNU&3^EM2+N}&sS+0YlJ1lw[6OvO%XTa%&LQ6[($So(f(@ P(@ Pgva(@ P(@ P(@q`G0s'(@ P(@ P@> 4F P(@ P(@ ;JDž;(@ P(@ PY|t7 P(@ P(@ P`\Q:. (@ P(@ P((üQ(@ P(@ P"qaN(@ P(@ P(@|`Gi>(@ P(@ Pv 3wB P(@ P(@ ;J0o(@ P(@ Pt\ P(@ P(@ P QGy(@ P(@ PE̝P(@ P(@ P,|>:(@ P(@ P(0.(f(@ P(@ Pgva(@ P(@ P(@q`G0s'(@ P(@ P@> 4F P(@ P(@ ;JDž;(@ P(@ PY|t7 P(@ P(@ P`\Q:. (@ P(@ P((üQ(@ P(@ P"P4.{)a{V*C@q&Vqpbw P`t3ΉkQ`,XgK]n 0]vIu]/~ke P`,Ν;.m P`ap(W3`f Sy%8`GinBS Cq0#KA P[MMMBh"/kQ^^"fXguV 2=(@ P(@ P`o?}(P(-[ .g\vex1G(@Ü 8(@ P(0E֮]$z:Ky;sHr+zrk(@ P(@1#W&ɬY`ۓ(@ P`vķ)@ P(@ P$0|hMړ1J9Q@(Mߌ)(@ P(@ P*pM7%ҥKuJ_(@(MI7(@ P(@ P)p7Cur-֗L P@ VVV𨀋ϢQȩ@^uj%kPP(@ P` h "R as 7X_2(@ P,SOʓ|Y4 P` _JJJ֬Y_(@ LE뮻uI{mŊ֗L P@ hw^'-c̢Q'w)'n3D P"W~#Iꪫ8>i _(@ ?akʻ3 ,(@ ]GiqJ9>in)?(@U:N)'U}D P(@ P ](SI=\ ]:N)'-#Q(@ Pc-qJ9>X} PSr|xg P(@ P 2 (@ 䋀66}C-ܒ/b>(@ P(@ LJ($qJ9>\1(087p8쑻(@ P(PyQ]s`ڵϒQ)X"-1)(@ P(@ +6N__s\f(@ L_ Q\\ G0T+v%_b)(0 ?rRc-0c lذc SY |;z&ΓH1(s!*(ͯP(@ P(@ P @.)@ P(@ P(@`Gi~(@ P(@ PvN:wI P(@ P(@ ;Jx07(@ P(@ PtйK P(@ P(@ P Q_ǃ(@ P(@ P&@]R(@ P(@ P%: (@ P(@ P(0(t(@ P(@ P/v`n(@ P(@ P(@ `Gs(@ P(@ P@~ 4sC P(@ P(@ L;J'(@ P(@ PKu< P(@ P(@ P`Q:%(@ P(@ P(_(ͯP(@ P(@ P @.)@ P(@ P(@`Gi~(@ P(@ PvN:wI P(@ P(@ ;Jx07(@ P(@ PtйK P(@ P(@ P Q_ǃ(@ P(@ P&@]R(@ P(@ P%: (@ P(@ P(0(t(@ P(@ P/sOg{1)%3(@ H`Zgh (@ Pd`Gdv}Usn<عm>"mp8?6g7W)kh voNx#}7)?*xnn4T&sJy]+OG5 x;w.][+BH2Fj*(@ P`r qjܚ{ u/YOBc? QIƴo|[oK*>[{bYOoˠrrKdƑ{v !j]ywT"g_wwQ&}sǃͨTb8\.ڿ?=ǷbsYwFH~6FsjǺ)@ L@!ӏY!>kT{\_c7QYIѶӛmKiݑڑw5(_BNOi_LbukC2Xok8&Öe fqFyb4a3g6rXwкW.O%=/_Ԍ4/iIi٘-h44ufZ޴A@$Nܖfی9x}0PW/]&mo5c%flb ?W(@ P /Jm~ːb[V:+b%l$Q۞4jtb`;6YWmو9A,jof4x\HRH\tRo}#ld*:#@غ<0 (@ Fqm_GzT؝8+܀BI*dYOڬ P`|rt{n|8R'6YZ,{~،<Dko8-CO rm~ zJ*ifGKټ -?*C8}ޢn@_:{_gkދ*f_ws^|v+Yu3w@ANj5w`ebh^y۠\n'*ο+v߆*Fۏx!*^.'{O/p9̽l%,elcM+^k(*Y!HqnoNʼnW T+à|h6[9t'^=Wega駮S;`[}eS/(@(:8n QSOx*zY!b}N ߩf\ua4۰e%rtxסFeb7?7BI#:{}<,= ;j ܿ.^e {ƄWݵp߱3}84~rU47߿s^3 | Uk\ASh~?W¶`-?v hs*qwbXΜ=}qDDŽq{~ļj'^~{msۥ׭$4='wPJRey9d±'U;M&;;(ŠEzHa'x]B\y <2W6JYo>_|( \ˑm;-<g`;ljt,'q;T>.5Įuw'>#6jt8qͿl)R9eObڛIxoVߋXs{i LC+Q~h'Gj}"eH(ӊ?@ֱ6y*_@|6w.q%IDATM/bDESO"ݾ{=yk.r{W[Jŗ[DOmw5VD}z#Vi۷jmxz-~~e-]/߯ XnT6/E(3hK2$p(ɮ6# p`|BSL} b+zmS~&ZaOnuM2@.ʮddrs 0+o%VGkO2lMS@@8Mq.=M [cW({$#P>cXeǔ8XgKnu4 5j|"h%mtF^=~p=٦ ZZ:MAKed}%RMu^ᩮ.KjzGx<^Ѩ5O:d0C%[ĭіWGuj;=#ywz{k!#^l"G:!U|F AcUVδl=BީS-oz{WVi|cSn5e/gXEt[}=c䨍tfKvi8BL6Fm phHlFKS ;CZxᏏ3#|#U!Qtfj㹩cY?@6sfCQ4Hd%Zo7Ωkp0GԹ-7v\"mڒXGvX1FK~p|1ʭL歏|ξ]'xJQkIfL>i7_3hkmЧS>ֿWRNZoϢ}-D:<lK }Fՙ,qdJ^he޳k 9{ L8`n߮]4jѼ؁]U˥q2֤-7#Y6=m2=r c !o翱 U7onYKźz[۰ڶ`W6{ǂ[ƣmU[fmmceB| 79e45::nOK]雐W\S oZT;O / R'>yq[ܨn@.aΜ j/8w܆M^y=T[!y-cԹ} h hmץqHseW% PSA,^{1Б=~|r}l#qG|\رq5)Wxtm[O9UI(+bd2M~lqƙwM/J~vJo9āAXeN&?ަnD.9+"N~u>mJ;|8[޺'MLkSM/oNxv7Zc7!Ԩ6sab]Zd}U+ߵxR,$v6nrW'OJr,q/lzR݁[sR- P`i_"VgܾfP{;#G㩽঵@ۯ5mjΆ. B5z !lZ*.iI]t|إ&y)gv]q 䭀֥yhvtW:ָrnS,5Yn7?ŴE=m6Մ` ɫ/LW}xY>QԤsWZψi%\2\9[eukOz_W+|Z(oO5rZ!/7^Y3yسJW&e:cb| :c{[.uS#7ؿKZ?@0sxrEiS;gOĻEXd3Jc31# ]"z+o7+Vcۆfa]mY Vؓa\~#7:~prz"{@Uv%g\(09XZm;Dof:Vt~iדىօp~fS|زv >h>)qu#F4x';EX$؟Ν$ƌzG[ZGqwwĶS DCG;uyU=ٱ1q˕uNu,'.>}_+{~]HޑslO?]Ae|EMg=jd׵9=rF.êbPPp]!d%JG\g$w-RXlջBw.[`)'UaN`~Ȭ}buGflcukyk݇_l"8mԲ+kD*Yrqdnk1\;VtoԓgwlbmbR @No `':i3N>8uf45vЋ_jc摷s;b:w|p;͗Wv'-x0Իx䍞F2?s/ҥ1|On"K2Gu>$M$;_F8' ܦl{jg?l:e+n?g)@ LRs;)´sHn)(W$geli]ٲ'mq߿j4:`ۜ?e^'I^]IYǏ4K.3BV"% X\ёan+G?~"L\7dx[%Rm55昽ڲu K^q\8τCtyPn@X=q}>,{t\>bSPuӴ $V(02i_˨0vZXaZգo_0_W>TQKlxH&z v.l\kCk(ߦ&LUtjiCeE77^//$̕sD[bPCtu*3p˱.=jmlJۊu8xz]@B\+8rn[Tiڧ6;WFy;8ʋ,;=4?~ }qjc)ejTYRq+î]?guJRW6`*=뷨1W9x/~Z5 ݋JKf˖+OZlH}7JO:L6帣Ŗ6Sl14GIա: N ȓv p.Ŧgȸat20U踩c\ne0Vg޾X=\U0>(ryzqbOfeA D6z=6^U߁hZOe;-ƚY(yeG~bgyv[ʥ^/c>UeGc8 \ʲmݺO.S(Lk||-%yrLP6 GS/J\ؿ69t-º͏oŘZ)n9xwM+&~[ch~->j.5nPk""rʳ~Bм[x/a"kP'qLg;fe`ڶO3Of4ɇ`P?{s+U AsƭJ8fϚk۾2/efǎ>r5tkz}8ڇdwϟ{?Eܻ&+JAng3aZ𮑶X|' hk渍TW(0Erվ~Φ}X.Ӿk<o6ݶ⻸E<gEu4:A 2tu.?ݱGvoJ!; ىR{ocb̜TF\o0<3X;V.N@V5:EpW>h) qcv5UNM>BKlYg (3"E{K>K D6x@}uE[U}hܞIDkU>Sl`epm-~!nɗOwFAm?^e]- _U;2mFcd.\- zmc“uu{3f¢ѭ#z²lz!/2xe7r3QsNT޹_ P`(aZ/:CwKʘPgcWZ\ $Ē.Q)Z"cubM._OHO.Klyb`$nhkCu8eyRSujS̋;/îd]J lm~\,Mp?>Q[{]9udaر픺|脥ޑW.&JUa|4ߞH}G,Q>"a<~2&!ҎM+Z6H{Y{ O*O lMY}=)XeZ~Bٶ`BwMBqQ ڂ2砍*4,oBoS []juT=>d%أ>\qGdzC]Zb5"(XkTN;LscJZnB^[w$~BX]׃TTk]Gm[ h>]jRiuZHSI/_}0VkOKdMQN6eGivkmx& BEk&>uNhQIhFʜ[&kUoAe7e}fNXιc P`,ƪ㡣܉ew]lH۵:d]hKs=$Tct + ۳yF@3eψ#V/qId~Ol˼NyW}6#Ԕ$Zf:NNҁO22lvQOmJM;qa b XHiie'*S8nrׁ;h'S%ñ㟱Dz2OS[`\cѾ-X}ZdU kMxeU2XOnQMM~y2t/M'#߰a>I-WDszu$5ek'b\c\n>r0 (O:oz?:SکRTUܹ\yż|fٵvY.m ].4xm;D^vώ8PI^/x<` +eQ'_5~_(PtiP3r:p_!lz"_=رm5ZgB];CFcom<*aam" ŷno UlkaeSE-S~TeWnC'1@OSɜs*)2[ݸ=aْ[0Mj)Sjb{K{|dᔟ8}Z3GOlJY P`2 EZ:m_#X=L+M5.ZxȪ|lڵlcw헡>WT}T}h%צ]o}jƱ6aK|L@;GO4Xn/ L]4txow-v;z_}# kf͆Zˮza)W#36z^jJ8ۤ+;mN-J2\DOk,$gh櫕R_QdN%")fks:y{lˮaNPƹ[ P`L P>kCNcB!ÔX/Vi cmy׈2]4w-sry+qI^syD_ߌ6O6u)l ѥ1V"R7teFcu{ &l:62D{qt=LtOn ؐ07mPlU(4Дnlӛ?'͟&7)ēIr{.Ͼ !M~g?n7rҝ]$5{!kB\/6p}+>G:y @\2Uo֏({ԭtld<-D\zF~X\: zKnD\e~#Caezӽiͧ%}VKg } ZW[*Ύ@@m_z%.;W/SO\u'}9Ffysx-8y󬙧z3zcGm%zh(ܔk\|sDzY'Nh9W>P\ݡEn#S5ΠOJ>Y]wHw\dDW_ѡ܍9~@<:!տD}tHvojK?zSQIp K0 MΈϺɴ.liPPשAw{/.ׯ_k:0^ZzV)Z ~VtQ5;c;sSV~K6)ԄL߾$oo}^"#՝I_"/Cv,J]B;:`yF5kd 8۬vYalRwf$rG[cr[lZufȷk80ؾqqy8}~-(=JIswRbuU1b V/Z)mJK.y@ܤ}&cLLco"icEIS-+V[-[[CWsCJ^"jq0Sr2$ν]B Cm- KC$t˿O}՗)æ^K9qnئ%hKMؕ]@j'OJ6~Z9hħu]c_ABB~Û;J)R?sm_cHvN,(bEӶ2 p2׌wTJF ^- w[T8.8Kz ⠶)y:ϙ?i(Ҩ[c>[eT 8(P:+>jh&]U$]/;Iw' f: -0{4meq oFd,TՎ9(em!$# PguVj"@.4xn<Z//AkFiDwtIkM/o,&`D蕃lSa>[  PXOt@KbjSvO;tmm䷟ʀ ݰn={lvPϧ"  E VMņ @ZAÅ-H_Γ^ߚt %.g++vd @ ؃BDߒ$M3K~IH\%ۯd^ֿ=Zmc @ V}S@4HE |/1 ;|4,sJרAR  P@ R&5HV[*e/ 6y  @muGpTm$8_,E@ eV&?l.g  _:  @~IE@@@@#@;uMI@@@@@ @C2    xG@wꚒ"    A@d@@@@R5%E@@@@R      ީkJ    @@@@@;JSה@@@@ J 0$#    wz))    `HF@@@@(N]SR@@@@0(5     Pꝺ     ` Pj!@@@@#@;uMI@@@@@ @C2    xG@wꚒ"    AJonn'O6!-011!> G ܺuK=*---.9E XW+W2k2vbSf' 0vvRmg^V$a255UT@GVZ傜E\vV< @U숀;k= 0vZuNҁRd     (CvzIENDB`DBI/vignettes/DBI-1.Rmd0000644000176200001440000005740013027447303014071 0ustar liggesusers--- title: "A Common Database Interface (DBI)" author: "R-Databases Special Interest Group" date: "16 June 2003" output: rmarkdown::html_vignette bibliography: biblio.bib vignette: > %\VignetteIndexEntry{A Common Database Interface (DBI)} %\VignetteEngine{knitr::rmarkdown} --- This document describes a common interface between the S language (in its R and S-Plus implementations) and database management systems (DBMS). The interface defines a small set of classes and methods similar in spirit to Perl’s DBI, Java’s JDBC, Python’s DB-API, and Microsoft’s ODBC. # Version {#sec:version} This document describes version 0.1-6 of the database interface API (application programming interface). # Introduction {#sec:intro} The database interface (DBI) separates the connectivity to the DBMS into a “front-end” and a “back-end”. Applications use only the exposed “front-end” API. The facilities that communicate with specific DBMS (Oracle, PostgreSQL, etc.) are provided by “device drivers” that get invoked automatically by the S language evaluator. The following example illustrates some of the DBI capabilities: ```R ## Choose the proper DBMS driver and connect to the server drv <- dbDriver("ODBC") con <- dbConnect(drv, "dsn", "usr", "pwd") ## The interface can work at a higher level importing tables ## as data.frames and exporting data.frames as DBMS tables. dbListTables(con) dbListFields(con, "quakes") if(dbExistsTable(con, "new_results")) dbRemoveTable(con, "new_results") dbWriteTable(con, "new_results", new.output) ## The interface allows lower-level interface to the DBMS res <- dbSendQuery(con, paste( "SELECT g.id, g.mirror, g.diam, e.voltage", "FROM geom_table as g, elec_measures as e", "WHERE g.id = e.id and g.mirrortype = 'inside'", "ORDER BY g.diam")) out <- NULL while(!dbHasCompleted(res)){ chunk <- fetch(res, n = 10000) out <- c(out, doit(chunk)) } ## Free up resources dbClearResult(res) dbDisconnect(con) dbUnloadDriver(drv) ``` (only the first 2 expressions are DBMS-specific – all others are independent of the database engine itself). Individual DBI drivers need not implement all the features we list below (we indicate those that are optional). Furthermore, drivers may extend the core DBI facilities, but we suggest to have these extensions clearly indicated and documented. The following are the elements of the DBI: 1. A set of classes and methods (Section [sec:DBIClasses]) that defines what operations are possible and how they are defined, e.g.: - connect/disconnect to the DBMS - create and execute statements in the DBMS - extract results/output from statements - error/exception handling - information (meta-data) from database objects - transaction management (optional) Some things are left explicitly unspecified, e.g., authentication and even the query language, although it is hard to avoid references to SQL and relational database management systems (RDBMS). 2. Drivers Drivers are collection of functions that implement the functionality defined above in the context of specific DBMS, e.g., mSQL, Informix. 3. Data type mappings (Section [sec:data-mappings].) Mappings and conversions between DBMS data types and R/S objects. All drivers should implement the “basic” primitives (see below), but may chose to add user-defined conversion function to handle more generic objects (e.g., factors, ordered factors, time series, arrays, images). 4. Utilities (Section [sec:utilities].) These facilities help with details such as mapping of identifiers between S and DBMS (e.g., `_` is illegal in R/S names, and `.` is used for constructing compound SQL identifiers), etc. # DBI Classes and Methods {#sec:DBIClasses} The following are the main DBI classes. They need to be extended by individual database back-ends (Sybase, Oracle, etc.) Individual drivers need to provide methods for the generic functions listed here (those methods that are optional are so indicated). *Note: Although R releases prior to 1.4 do not have a formal concept of classes, we will use the syntax of the S Version 4 classes and methods (available in R releases 1.4 and later as library `methods`) to convey precisely the DBI class hierarchy, its methods, and intended behavior.* The DBI classes are `DBIObject`, `DBIDriver`, `DBIConnection` and `DBIResult`. All these are *virtual* classes. Drivers define new classes that extend these, e.g., `PgSQLDriver`, `PgSQLConnection`, and so on. ![Class hierarchy for the DBI. The top two layers are comprised of virtual classes and each lower layer represents a set of driver-specific implementation classes that provide the functionality defined by the virtual classes above.](hierarchy.png) `DBIObject`: : Virtual class[^1] that groups all other DBI classes. `DBIDriver`: : Virtual class that groups all DBMS drivers. Each DBMS driver extends this class. Typically generator functions instantiate the actual driver objects, e.g., `PgSQL`, `HDF5`, `BerkeleyDB`. `DBIConnection`: : Virtual class that encapsulates connections to DBMS. `DBIResult`: : Virtual class that describes the result of a DBMS query or statement. [Q: Should we distinguish between a simple result of DBMS statements e.g., as `delete` from DBMS queries (i.e., those that generate data).] The methods `format`, `print`, `show`, `dbGetInfo`, and `summary` are defined (and *implemented* in the `DBI` package) for the `DBIObject` base class, thus available to all implementations; individual drivers, however, are free to override them as they see fit. `format(x, ...)`: : produces a concise character representation (label) for the `DBIObject` `x`. `print(x, ...)`/`show(x)`: : prints a one-line identification of the object `x`. `summary(object, ...)`: : produces a concise description of the object. The default method for `DBIObject` simply invokes `dbGetInfo(dbObj)` and prints the name-value pairs one per line. Individual implementations may tailor this appropriately. `dbGetInfo(dbObj, ...)`: : extracts information (meta-data) relevant for the `DBIObject` `dbObj`. It may return a list of key/value pairs, individual meta-data if supplied in the call, or `NULL` if the requested meta-data is not available. *Hint:* Driver implementations may choose to allow an argument `what` to specify individual meta-data, e.g., `dbGetInfo(drv, what = max.connections)`. In the next few sub-sections we describe in detail each of these classes and their methods. ## Class `DBIObject` {#sec:DBIObject} This class simply groups all DBI classes, and thus all extend it. ## Class `DBIDriver` {#sec:DBIDriver} This class identifies the database management system. It needs to be extended by individual back-ends (Oracle, PostgreSQL, etc.) The DBI provides the generator `dbDriver(driverName)` which simply invokes the function `driverName`, which in turn instantiates the corresponding driver object. The `DBIDriver` class defines the following methods: `driverName`: : [meth:driverName] initializes the driver code. The name `driverName` refers to the actual generator function for the DBMS, e.g., `RPgSQL`, `RODBC`, `HDF5`. The driver instance object is used with `dbConnect` (see page ) for opening one or possibly more connections to one or more DBMS. `dbListConnections(drv, ...)`: : list of current connections being handled by the `drv` driver. May be `NULL` if there are no open connections. Drivers that do not support multiple connections may return the one open connection. `dbGetInfo(dbObj, ...)`: : returns a list of name-value pairs of information about the driver. *Hint:* Useful entries could include `name`: : the driver name (e.g., `RODBC`, `RPgSQL`); `driver.version`: : version of the driver; `DBI.version`: : the version of the DBI that the driver implements, e.g., `0.1-2`; `client.version`: : of the client DBMS libraries (e.g., version of the `libpq` library in the case of `RPgSQL`); `max.connections`: : maximum number of simultaneous connections; plus any other relevant information about the implementation, for instance, how the driver handles upper/lower case in identifiers. `dbUnloadDriver(driverName)` (optional): : frees all resources (local and remote) used by the driver. Returns a logical to indicate if it succeeded or not. ## Class `DBIConnection` {#sec:DBIConnection} This virtual class encapsulates the connection to a DBMS, and it provides access to dynamic queries, result sets, DBMS session management (transactions), etc. *Note:* Individual drivers are free to implement single or multiple simultaneous connections. The methods defined by the `DBIConnection` class include: `dbConnect(drv, ...)`: : [meth:dbConnect] creates and opens a connection to the database implemented by the driver `drv` (see Section [sec:DBIDriver]). Each driver will define what other arguments are required, e.g., `dbname` or `dsn` for the database name, `user`, and `password`. It returns an object that extends `DBIConnection` in a driver-specific manner (e.g., the MySQL implementation could create an object of class `MySQLConnection` that extends `DBIConnection`). `dbDisconnect(conn, ...)`: : closes the connection, discards all pending work, and frees resources (e.g., memory, sockets). Returns a logical indicating whether it succeeded or not. `dbSendQuery(conn, statement, ...)`: : submits one statement to the DBMS. It returns a `DBIResult` object. This object is needed for fetching data in case the statement generates output (see `fetch` on page ), and it may be used for querying the state of the operation; see `dbGetInfo` and other meta-data methods on page . `dbGetQuery(conn, statement, ...)`: : submit, execute, and extract output in one operation. The resulting object may be a `data.frame` if the `statement` generates output. Otherwise the return value should be a logical indicating whether the query succeeded or not. `dbGetException(conn, ...)`: : returns a list with elements `errNum` and `errMsg` with the status of the last DBMS statement sent on a given connection (this information may also be provided by the `dbGetInfo` meta-data function on the `conn` object. *Hint:* The ANSI SQL-92 defines both a status code and an status message that could be return as members of the list. `dbGetInfo(dbObj, ...)`: : returns a list of name-value pairs describing the state of the connection; it may return one or more meta-data, the actual driver method allows to specify individual pieces of meta-data (e.g., maximum number of open results/cursors). *Hint:* Useful entries could include `dbname`: : the name of the database in use; `db.version`: : the DBMS server version (e.g., “Oracle 8.1.7 on Solaris”; `host`: : host where the database server resides; `user`: : user name; `password`: : password (is this safe?); plus any other arguments related to the connection (e.g., thread id, socket or TCP connection type). `dbListResults(conn, ...)`: : list of `DBIResult` objects currently active on the connection `conn`. May be `NULL` if no result set is active on `conn`. Drivers that implement only one result set per connection could return that one object (no need to wrap it in a list). *Note: The following are convenience methods that simplify the import/export of (mainly) data.frames. The first five methods implement the core methods needed to `attach` remote DBMS to the S search path. (For details, see @data-management:1991 [@database-classes:1999].)* *Hint:* For relational DBMS these methods may be easily implemented using the core DBI methods `dbConnect`, `dbSendQuery`, and `fetch`, due to SQL reflectance (i.e., one easily gets this meta-data by querying the appropriate tables on the RDBMS). `dbListTables(conn, ...)`: : returns a character vector (possibly of zero-length) of object (table) names available on the `conn` connection. `dbReadTable(conn, name, ...)`: : imports the data stored remotely in the table `name` on connection `conn`. Use the field `row.names` as the `row.names` attribute of the output data.frame. Returns a `data.frame`. [Q: should we spell out how row.names should be created? E.g., use a field (with unique values) as row.names? Also, should `dbReadTable` reproduce a data.frame exported with `dbWriteTable`?] `dbWriteTable(conn, name, value, ...)`: : write the object `value` (perhaps after coercing it to data.frame) into the remote object `name` in connection `conn`. Returns a logical indicating whether the operation succeeded or not. `dbExistsTable(conn, name, ...)`: : does remote object `name` exist on `conn`? Returns a logical. `dbRemoveTable(conn, name, ...)`: : removes remote object `name` on connection `conn`. Returns a logical indicating whether the operation succeeded or not. `dbListFields(conn, name, ...)`: : returns a character vector listing the field names of the remote table `name` on connection `conn` (see `dbColumnInfo()` for extracting data type on a table). *Note: The following methods deal with transactions and stored procedures. All these functions are optional.* `dbCommit(conn, ...)`(optional): : commits pending transaction on the connection and returns `TRUE` or `FALSE` depending on whether the operation succeeded or not. `dbRollback(conn, ...)`(optional): : undoes current transaction on the connection and returns `TRUE` or `FALSE` depending on whether the operation succeeded or not. `dbCallProc(conn, storedProc, ...)`(optional): : invokes a stored procedure in the DBMS and returns a `DBIResult` object. [Stored procedures are *not* part of the ANSI SQL-92 standard and vary substantially from one RDBMS to another.] ## Class `DBIResult` {#sec:DBIResult} This virtual class describes the result and state of execution of a DBMS statement (any statement, query or non-query). The result set `res` keeps track of whether the statement produces output for R/S, how many rows were affected by the operation, how many rows have been fetched (if statement is a query), whether there are more rows to fetch, etc. *Note: Individual drivers are free to allow single or multiple active results per connection.* [Q: Should we distinguish between results that return no data from those that return data?] The class `DBIResult` defines the following methods: `fetch(res, n, ...)`: : [meth:fetch] fetches the next `n` elements (rows) from the result set `res` and return them as a data.frame. A value of `n=-1` is interpreted as “return all elements/rows”. `dbClearResult(res, ...)`: : flushes any pending data and frees all resources (local and remote) used by the object `res` on both sides of the connection. Returns a logical indicating success or not. `dbGetInfo(dbObj, ...)`: : returns a name-value list with the state of the result set. *Hint:* Useful entries could include `statement`: : a character string representation of the statement being executed; `rows.affected`: : number of affected records (changed, deleted, inserted, or extracted); `row.count`: : number of rows fetched so far; `has.completed`: : has the statement (query) finished? `is.select`: : a logical describing whether or not the statement generates output; plus any other relevant driver-specific meta-data. `dbColumnInfo(res, ...)`: : produces a data.frame that describes the output of a query. The data.frame should have as many rows as there are output fields in the result set, and each column in the data.frame should describe an aspect of the result set field (field name, type, etc.) *Hint:* The data.frame columns could include `field.name`: : DBMS field label; `field.type`: : DBMS field type (implementation-specific); `data.type`: : corresponding R/S data type, e.g., `integer`; `precision`/`scale`: : (as in ODBC terminology), display width and number of decimal digits, respectively; `nullable`: : whether the corresponding field may contain (DBMS) `NULL` values; plus other driver-specific information. `dbSetDataMappings(flds, ...)`(optional): : defines a conversion between internal DBMS data types and R/S classes. We expect the default mappings (see Section [sec:data-mappings]) to be by far the most common ones, but users that need more control may specify a class generator for individual fields in the result set. [This topic needs further discussion.] *Note: The following are convenience methods that extract information from the result object (they may be implemented by invoking `dbGetInfo` with appropriate arguments).* `dbGetStatement(res, ...)`(optional): : returns the DBMS statement (as a character string) associated with the result `res`. `dbGetRowsAffected(res, ...)`(optional): : returns the number of rows affected by the executed statement (number of records deleted, modified, extracted, etc.) `dbHasCompleted(res, ...)`(optional): : returns a logical that indicates whether the operation has been completed (e.g., are there more records to be fetched?). `dbGetRowCount(res, ...)`(optional): : returns the number of rows fetched so far. # Data Type Mappings {#sec:data-mappings} The data types supported by databases are different than the data types in R and S, but the mapping between the “primitive” types is straightforward: Any of the many fixed and varying length character types are mapped to R/S `character`. Fixed-precision (non-IEEE) numbers are mapped into either doubles (`numeric`) or long (`integer`). Notice that many DBMS do not follow the so-called IEEE arithmetic, so there are potential problems with under/overflows and loss of precision, but given the R/S primitive types we cannot do too much but identify these situations and warn the application (how?). By default dates and date-time objects are mapped to character using the appropriate `TO_CHAR` function in the DBMS (which should take care of any locale information). Some RDBMS support the type `CURRENCY` or `MONEY` which should be mapped to `numeric` (again with potential round off errors). Large objects (character, binary, file, etc.) also need to be mapped. User-defined functions may be specified to do the actual conversion (as has been done in other inter-systems packages [^2]). Specifying user-defined conversion functions still needs to be defined. # Utilities {#sec:utilities} The core DBI implementation should make available to all drivers some common basic utilities. For instance: `dbGetDBIVersion`: : returns the version of the currently attached DBI as a string. `dbDataType(dbObj, obj, ...)`: : returns a string with the (approximately) appropriate data type for the R/S object `obj`. The DBI can implement this following the ANSI-92 standard, but individual drivers may want/need to extend it to make use of DBMS-specific types. `make.db.names(dbObj, snames, ...)`: : maps R/S names (identifiers) to SQL identifiers replacing illegal characters (as `.`) by the legal SQL `_`. `SQLKeywords(dbObj, ...)`: : returns a character vector of SQL keywords (reserved words). The default method returns the list of `.SQL92Keywords`, but drivers should update this vector with the DBMS-specific additional reserved words. `isSQLKeyword(dbObj, name, ...)`: : for each element in the character vector `name` determine whether or not it is an SQL keyword, as reported by the generic function `SQLKeywords`. Returns a logical vector parallel to the input object `name`. # Open Issues and Limitations {#sec:open-issues} There are a number of issues and limitations that the current DBI conscientiously does not address on the interest of simplicity. We do list here the most important ones. Non-SQL: : Is it realistic to attempt to encompass non-relational databases, like HDF5, Berkeley DB, etc.? Security: : allowing users to specify their passwords on R/S scripts may be unacceptable for some applications. We need to consider alternatives where users could store authentication on files (perhaps similar to ODBC’s `odbc.ini`) with more stringent permissions. Exceptions: : the exception mechanism is a bit too simple, and it does not provide for information when problems stem from the DBMS interface itself. For instance, under/overflow or loss of precision as we move numeric data from DBMS to the more limited primitives in R/S. Asynchronous communication: : most DBMS support both synchronous and asynchronous communications, allowing applications to submit a query and proceed while the database server process the query. The application is then notified (or it may need to poll the server) when the query has completed. For large computations, this could be very useful, but the DBI would need to specify how to interrupt the server (if necessary) plus other details. Also, some DBMS require applications to use threads to implement asynchronous communication, something that neither R nor S-Plus currently addresses. SQL scripts: : the DBI only defines how to execute one SQL statement at a time, forcing users to split SQL scripts into individual statements. We need a mechanism by which users can submit SQL scripts that could possibly generate multiple result sets; in this case we may need to introduce new methods to loop over multiple results (similar to Python’s `nextResultSet`). BLOBS/CLOBS: : large objects (both character and binary) present some challenges both to R and S-Plus. It is becoming more common to store images, sounds, and other data types as binary objects in DBMS, some of which can be in principle quite large. The SQL-92 ANSI standard allows up to 2 gigabytes for some of these objects. We need to carefully plan how to deal with binary objects. Transactions: : transaction management is not fully described. Additional methods: : Do we need any additional methods? (e.g., `dbListDatabases(conn)`, `dbListTableIndices(conn, name)`, how do we list all available drivers?) Bind variables: : the interface is heavily biased towards queries, as opposed to general purpose database development. In particular we made no attempt to define “bind variables”; this is a mechanism by which the contents of R/S objects are implicitly moved to the database during SQL execution. For instance, the following embedded SQL statement /* SQL */ SELECT * from emp_table where emp_id = :sampleEmployee would take the vector `sampleEmployee` and iterate over each of its elements to get the result. Perhaps the DBI could at some point in the future implement this feature. # Resources {#sec:resources} The idea of a common interface to databases has been successfully implemented in various environments, for instance: Java’s Database Connectivity (JDBC) ([www.javasoft.com](http://www.javasoft.com/products/jdbc/index.html)). In C through the Open Database Connectivity (ODBC) ([www.unixodbc.org](http://www.unixodbc.org/)). Python’s Database Application Programming Interface ([www.python.org](http://www.python.org/topics/database)). Perl’s Database Interface ([dbi.perl.org](http://dbi.perl.org)). [^1]: A virtual class allows us to group classes that share some common characteristics, even if their implementations are radically different. [^2]: Duncan Temple Lang has volunteered to port the data conversion code found in R-Java, R-Perl, and R-Python packages to the DBI DBI/vignettes/spec.Rmd0000644000176200001440000001115613060005002014244 0ustar liggesusers--- title: "DBI specification" author: "Kirill Müller" date: "`r Sys.Date()`" output: rmarkdown::html_document: smart: FALSE toc: TRUE toc_float: TRUE abstract: > The DBI package defines the generic DataBase Interface for R. The connection to individual DBMS is provided by other packages that import DBI (so-called *DBI backends*). This document formalizes the behavior expected by the methods declared in DBI and implemented by the individual backends. To ensure maximum portability and exchangeability, and to reduce the effort for implementing a new DBI backend, the DBItest package defines a comprehensive set of test cases that test conformance to the DBI specification. This document is derived from comments in the test definitions of the DBItest package. Any extensions or updates to the tests will be reflected in this document. vignette: > %\VignetteIndexEntry{DBI specification} %\VignetteEngine{knitr::rmarkdown} %\VignetteEncoding{UTF-8} --- ```{r echo = FALSE} library(magrittr) library(xml2) knitr::opts_chunk$set(echo = FALSE) r <- rprojroot::is_r_package$make_fix_file() ``` ```{r error=TRUE} rd_db <- tools::Rd_db(dir = r()) Links <- tools::findHTMLlinks() html_topic <- function(name) { rd <- rd_db[[paste0(name, ".Rd")]] conn <- textConnection(NULL, "w") on.exit(close(conn)) #tools::Rd2HTML(rd, conn, Links = Links) tools::Rd2HTML(rd, conn) textConnectionValue(conn) } xml_topic <- function(name, patcher) { html <- html_topic(name) x <- read_html(paste(html, collapse = "\n")) # No idea why this is necessary when embedding HTML in Markdown codes <- x %>% xml_find_all("//code[contains(., '$')]") xml_text(codes) <- gsub("[$]", "\\\\$", xml_text(codes)) xx <- x %>% xml_find_first("/html/body") xx %>% xml_find_first("//table") %>% xml_remove() patcher(xx) } asis_topic <- function(name, patcher = identity) { xml <- lapply(name, xml_topic, patcher = patcher) asis <- sapply(xml, as.character) %>% paste(collapse = "\n") knitr::asis_output(asis) } patch_package_doc <- function(x) { x %>% xml_find_first("//h3") %>% xml_remove remove_see_also_section(x) remove_authors_section(x) x } move_contents_of_usage_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 usage_contents <- x %>% xml_find_all( "//h3[.='Usage']/following-sibling::node() [not(self::h3)] [count(preceding-sibling::h3)=2]") usage_text <- usage_contents %>% xml_find_first("//pre") %>% xml_text h3 <- x %>% xml_find_first("//h3") intro_text <- read_xml( paste0( "

This section describes the behavior of the following method", if (length(grep("[(]", strsplit(usage_text, "\n")[[1]])) > 1) "s" else "", ":

") ) xml_add_sibling( h3, intro_text, .where = "before") lapply(usage_contents, xml_add_sibling, .x = h3, .copy = FALSE, .where = "before") x %>% xml_find_first("//h3[.='Usage']") %>% xml_remove x } move_additional_arguments_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error additional_arguments <- x %>% xml_find_all( "//h3[.='Additional arguments'] | //h3[.='Additional arguments']/following-sibling::node()[following-sibling::h3]") after_arg <- x %>% xml_find_first("//h3[text()='Arguments']/following-sibling::h3") lapply(additional_arguments, xml_add_sibling, .x = after_arg, .copy = FALSE, .where = "before") x } remove_see_also_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error x %>% xml_find_all( "//h3[.='See Also'] | //h3[.='See Also']/following-sibling::node()[following-sibling::h3]") %>% xml_remove() x } remove_authors_section <- function(x) { # http://stackoverflow.com/a/3839299/946850 and some trial and error x %>% xml_find_all( "//h3[.='Author(s)'] | //h3[.='Author(s)']/following-sibling::node()[following-sibling::h3]") %>% xml_remove() x } patch_method_doc <- function(x) { move_contents_of_usage_section(x) remove_see_also_section(x) move_additional_arguments_section(x) x } asis_topic("DBI-package", patch_package_doc) topics <- c( "dbDataType", "dbConnect", "dbDisconnect", "dbSendQuery", "dbFetch", "dbClearResult", "dbBind", "dbGetQuery", "dbSendStatement", "dbExecute", "dbQuoteString", "dbQuoteIdentifier", "dbReadTable", "dbWriteTable", "dbListTables", "dbExistsTable", "dbRemoveTable", "dbIsValid", "dbHasCompleted", "dbGetStatement", "dbGetRowCount", "dbGetRowsAffected", "transactions", "dbWithTransaction" ) asis_topic(topics, patch_method_doc) ``` DBI/vignettes/DBI-proposal.Rmd0000644000176200001440000006646313054310030015563 0ustar liggesusers--- title: "A Common Interface to Relational Databases from R and S -- A Proposal" author: "David James" date: "March 16, 2000" output: rmarkdown::html_vignette bibliography: biblio.bib vignette: > %\VignetteIndexEntry{A Common Interface to Relational Databases from R and S -- A Proposal} %\VignetteEngine{knitr::rmarkdown} --- For too long S and similar data analysis environments have lacked good interfaces to relational database systems (RDBMS). For the last twenty years or so these RDBMS have evolved into highly optimized client-server systems for data storage and manipulation, and currently they serve as repositories for most of the business, industrial, and research “raw” data that analysts work with. Other analysis packages, such as SAS, have traditionally provided good data connectivity, but S and GNU R have relied on intermediate text files as means of importing data (but see @R.imp-exp and @R-dbms.) Although this simple approach works well for relatively modest amounts of mostly static data, it does not scale up to larger amounts of data distributed over machines and locations, nor does it scale up to data that is highly dynamic – situations that are becoming increasingly common. We want to propose a common interface between R/S and RDBMS that would allow users to access data stored on database servers in a uniform and predictable manner irrespective of the database engine. The interface defines a small set of classes and methods similar in spirit to Python’s DB-API, Java’s JDBC, Microsoft’s ODBC, Perl’s DBI, etc., but it conforms to the “whole-object” philosophy so natural in S and R. # Computing with Distributed Data {#sec:distr} As data analysts, we are increasingly faced with the challenge of larger data sources distributed over machines and locations; most of these data sources reside in relational database management systems (RDBMS). These relational databases represent a mature client-server distributed technology that we as analysts could be exploiting more that we’ve done in the past. The relational technology provides a well-defined standard, the ANSI SQL-92 @sql92, both for defining and manipulating data in a highly optimized fashion from virtually any application. In contrast, S and Splus have provided somewhat limited tools for coping with the challenges of larger and distributed data sets (Splus does provide an `import` function to import from databases, but it is quite limited in terms of SQL facilities). The R community has been more resourceful and has developed a number of good libraries for connecting to mSQL, MySQL, PostgreSQL, and ODBC; each library, however, has defined its own interface to each database engine a bit differently. We think it would be to everybody’s advantage to coordinate the definition of a common interface, an effort not unlike those taken in the Python and Perl communities. The goal of a common, seamless access to distributed data is a modest one in our evolution towards a fully distributed computing environment. We recognize the greater goal of distributed computing as the means to fully integrate diverse systems – not just databases – into a truly flexible analysis environment. Good connectivity to databases, however, is of immediate necessity both in practical terms and as a means to help us transition from monolithic, self-contained systems to those in which computations, not only the data, can be carried out in parallel over a wide number of computers and/or systems @duncan2000. Issues of reliability, security, location transparency, persistence, etc., will be new to most of us and working with distributed data may provide a more gradual change to ease in the ultimate goal of full distributed computing. # A Common Interface {#sec:rs-dbi} We believe that a common interface to databases can help users easily access data stored in RDBMS. A common interface would describe, in a uniform way, how to connect to RDBMS, extract meta-data (such as list of available databases, tables, etc.) as well as a uniform way to execute SQL statements and import their output into R and S. The current emphasis is on querying databases and not so much in a full low-level interface for database development as in JDBC or ODBC, but unlike these, we want to approach the interface from the “whole-object” perspective @S4 so natural to R/S and Python – for instance, by fetching all fields and records simultaneously into a single object. The basic idea is to split the interface into a front-end consisting of a few classes and generic functions that users invoke and a back-end set of database-specific classes and methods that implement the actual communication. (This is a very well-known pattern in software engineering, and another good verbatim is the device-independent graphics in R/S where graphics functions produce similar output on a variety of different devices, such X displays, Postscript, etc.) The following verbatim shows the front-end: ``` > mgr <- dbManager("Oracle") > con <- dbConnect(mgr, user = "user", passwd = "passwd") > rs <- dbExecStatement(con, "select fld1, fld2, fld3 from MY_TABLE") > tbls <- fetch(rs, n = 100) > hasCompleted(rs) [1] T > close(rs) > rs <- dbExecStatement(con, "select id_name, q25, q50 from liv2") > res <- fetch(rs) > getRowCount(rs) [1] 73 > close(con) ``` Such scripts should work with other RDBMS (say, MySQL) by replacing the first line with ``` > mgr <- dbManager("MySQL") ``` ## Interface Classes {#sec:rs-dbi-classes} The following are the main RS-DBI classes. They need to be extended by individual database back-ends (MySQL, Oracle, etc.) `dbManager` : Virtual class[^2] extended by actual database managers, e.g., Oracle, MySQL, Informix. `dbConnection` : Virtual class that captures a connection to a database instance[^3]. `dbResult` : Virtual class that describes the result of an SQL statement. `dbResultSet` : Virtual class, extends `dbResult` to fully describe the output of those statements that produce output records, i.e., `SELECT` (or `SELECT`-like) SQL statement. All these classes should implement the methods `show`, `describe`, and `getInfo`: `show` : (`print` in R) prints a one-line identification of the object. `describe` : prints a short summary of the meta-data of the specified object (like `summary` in R/S). `getInfo` : takes an object of one of the above classes and a string specifying a meta-data item, and it returns the corresponding information (`NULL` if unavailable). > mgr <- dbManager("MySQL") > getInfo(mgr, "version") > con <- dbConnect(mgr, ...) > getInfo(con, "type") The reason we implement the meta-data through `getInfo` in this way is to simplify the writing of database back-ends. We don’t want to overwhelm the developers of drivers (ourselves, most likely) with hundreds of methods as in the case of JDBC. In addition, the following methods should also be implemented: `getDatabases` : lists all available databases known to the `dbManager`. `getTables` : lists tables in a database. `getTableFields` : lists the fields in a table in a database. `getTableIndices` : lists the indices defined for a table in a database. These methods may be implemented using the appropriate `getInfo` method above. In the next few sections we describe in detail each of these classes and their methods. ### Class `dbManager` {#sec:dbManager} This class identifies the relational database management system. It needs to be extended by individual back-ends (Oracle, PostgreSQL, etc.) The `dbManager` class defines the following methods: `load` : initializes the driver code. We suggest having the generator, `dbManager(driver)`, automatically load the driver. `unload` : releases whatever resources the driver is using. `getVersion` : returns the version of the RS-DBI currently implemented, plus any other relevant information about the implementation itself and the RDBMS being used. ### Class `dbConnection` {#sec:dbConnection} This virtual class captures a connection to a RDBMS, and it provides access to dynamic SQL, result sets, RDBMS session management (transactions), etc. Note that the `dbManager` may or may not allow multiple simultaneous connections. The methods it defines include: `dbConnect` : opens a connection to the database `dbname`. Other likely arguments include `host`, `user`, and `password`. It returns an object that extends `dbConnection` in a driver-specific manner (e.g., the MySQL implementation creates a connection of class `MySQLConnection` that extends `dbConnection`). Note that we could separate the steps of connecting to a RDBMS and opening a database there (i.e., opening an *instance*). For simplicity we do the 2 steps in this method. If the user needs to open another instance in the same RDBMS, just open a new connection. `close` : closes the connection and discards all pending work. `dbExecStatement` : submits one SQL statement. It returns a `dbResult` object, and in the case of a `SELECT` statement, the object also inherits from `dbResultSet`. This `dbResultSet` object is needed for fetching the output rows of `SELECT` statements. The result of a non-`SELECT` statement (e.g., `UPDATE, DELETE, CREATE, ALTER`, ...) is defined as the number of rows affected (this seems to be common among RDBMS). `commit` : commits pending transaction (optional). `rollback` : undoes current transaction (optional). `callProc` : invokes a stored procedure in the RDBMS (tentative). Stored procedures are *not* part of the ANSI SQL-92 standard and possibly vary substantially from one RDBMS to another. For instance, Oracle seems to have a fairly decent implementation of stored procedures, but MySQL currently does not support them. `dbExec` : submit an SQL “script” (multiple statements). May be implemented by looping with `dbExecStatement`. `dbNextResultSet` : When running SQL scripts (multiple statements), it closes the current result set in the `dbConnection`, executes the next statement and returns its result set. ### Class `dbResult` {#sec:dbResult} This virtual class describes the result of an SQL statement (any statement) and the state of the operation. Non-query statements (e.g., `CREATE`, `UPDATE`, `DELETE`) set the “completed” state to 1, while `SELECT` statements to 0. Error conditions set this slot to a negative number. The `dbResult` class defines the following methods: `getStatement` : returns the SQL statement associated with the result set. `getDBConnection` : returns the `dbConnection` associated with the result set. `getRowsAffected` : returns the number of rows affected by the operation. `hasCompleted` : was the operation completed? `SELECT`’s, for instance, are not completed until their output rows are all fetched. `getException` : returns the status of the last SQL statement on a given connection as a list with two members, status code and status description. ### Class `dbResultSet` {#sec:dbResultSet} This virtual class extends `dbResult`, and it describes additional information from the result of a `SELECT` statement and the state of the operation. The `completed` state is set to 0 so long as there are pending rows to fetch. The `dbResultSet` class defines the following additional methods: `getRowCount` : returns the number of rows fetched so far. `getNullOk` : returns a logical vector with as many elements as there are fields in the result set, each element describing whether the corresponding field accepts `NULL` values. `getFields` : describes the `SELECT`ed fields. The description includes field names, RDBMS internal data types, internal length, internal precision and scale, null flag (i.e., column allows `NULL`’s), and corresponding S classes (which can be over-ridden with user-provided classes). The current MySQL and Oracle implementations define a `dbResultSet` as a named list with the following elements: `connection`: : the connection object associated with this result set; `statement`: : a string with the SQL statement being processed; `description`: : a field description `data.frame` with as many rows as there are fields in the `SELECT` output, and columns specifying the `name`, `type`, `length`, `precision`, `scale`, `Sclass` of the corresponding output field. `rowsAffected`: : the number of rows that were affected; `rowCount`: : the number of rows so far fetched; `completed`: : a logical value describing whether the operation has completed or not. `nullOk`: : a logical vector specifying whether the corresponding column may take NULL values. The methods above are implemented as accessor functions to this list in the obvious way. `setDataMappings` : defines a conversion between internal RDBMS data types and R/S classes. We expect the default mappings to be by far the most common ones, but users that need more control may specify a class generator for individual fields in the result set. (See Section [sec:mappings] for details.) `close` : closes the result set and frees resources both in R/S and the RDBMS. `fetch` : extracts the next `max.rec` records (-1 means all). ## Data Type Mappings {#sec:mappings} The data types supported by databases are slightly different than the data types in R and S, but the mapping between them is straightforward: Any of the many fixed and varying length character types are mapped to R/S `character`. Fixed-precision (non-IEEE) numbers are mapped into either doubles (`numeric`) or long (`integer`). Dates are mapped to character using the appropriate `TO_CHAR` function in the RDBMS (which should take care of any locale information). Some RDBMS support the type `CURRENCY` or `MONEY` which should be mapped to `numeric`. Large objects (character, binary, file, etc.) also need to be mapped. User-defined functions may be specified to do the actual conversion as follows: 1. run the query (either with `dbExec` or `dbExecStatement`): > rs <- dbExecStatement(con, "select whatever-You-need") 2. extract the output field definitions > flds <- getFields(rs) 3. replace the class generator in the, say 3rd field, by the user own generator: > flds[3, "Sclass"] # default mapping [1] "character" by > flds[3, "Sclass"] <- "myOwnGeneratorFunction" 4. set the new data mapping prior to fetching > setDataMappings(resutlSet, flds) 5. fetch the rows and store in a `data.frame` > data <- fetch(resultSet) ## Open Issues {#sec:open-issues} We may need to provide some additional utilities, for instance to convert dates, to escape characters such as quotes and slashes in query strings, to strip excessive blanks from some character fields, etc. We need to decide whether we provide hooks so these conversions are done at the C level, or do all the post-processing in R or S. Another issue is what kind of data object is the output of an SQL query. Currently the MySQL and Oracle implementations return data as a `data.frame`; data frames have the slight inconvenience that they automatically re-label the fields according to R/S syntax, changing the actual RDBMS labels of the variables; the issue of non-numeric data being coerced into factors automatically “at the drop of a hat” (as someone in s-news wrote) is also annoying. The execution of SQL scripts is not fully described. The method that executes scripts could run individual statements without returning until it encounters a query (`SELECT`-like) statement. At that point it could return that one result set. The application is then responsible for fetching these rows, and then for invoking `dbNextResultSet` on the opened `dbConnection` object to repeat the `dbExec`/`fetch` loop until it encounters the next `dbResultSet`. And so on. Another (potentially very expensive) alternative would be to run all statements sequentially and return a list of `data.frame`s, each element of the list storing the result of each statement. Binary objects and large objects present some challenges both to R and S. It is becoming more common to store images, sounds, and other data types as binary objects in RDBMS, some of which can be in principle quite large. The SQL-92 ANSI standard allows up to 2 gigabytes for some of these objects. We need to carefully plan how to deal with binary objects – perhaps tentatively not in full generality. Large objects could be fetched by repeatedly invoking a specified R/S function that takes as argument chunks of a specified number of raw bytes. In the case of S4 (and Splus5.x) the RS-DBI implementation can write into an opened connection for which the user has defined a reader (but can we guarantee that we won’t overflow the connection?). In the case of R it is not clear what data type binary large objects (BLOB) should be mapped into. ## Limitations {#sec:limitations} These are some of the limitations of the current interface definition: - we only allow one SQL statement at a time, forcing users to split SQL scripts into individual statements; - transaction management is not fully described; - the interface is heavily biased towards queries, as opposed to general purpose database development. In particular we made no attempt to define “bind variables”; this is a mechanism by which the contents of S objects are implicitly moved to the database during SQL execution. For instance, the following embedded SQL statement /* SQL */ SELECT * from emp_table where emp_id = :sampleEmployee would take the vector `sampleEmployee` and iterate over each of its elements to get the result. Perhaps RS-DBI could at some point in the future implement this feature. # Other Approaches The high-level, front-end description of RS-DBI is the more critical aspect of the interface. Details on how to actually implement this interface may change over time. The approach described in this document based on one back-end driver per RDBMS is reasonable, but not the only approach – we simply felt that a simpler approach based on well-understood and self-contained tools (R, S, and C API’s) would be a better start. Nevertheless we want to briefly mention a few alternatives that we considered and tentatively decided against, but may quite possibly re-visit in the near future. ## Open Database Connectivity (ODBC) {#sec:odbc} The ODBC protocol was developed by Microsoft to allow connectivity among C/C++ applications and RDBMS. As you would expect, originally implementations of the ODBC were only available under Windows environments. There are various effort to create a Unix implementation (see [the Unix ODBC](http://www.unixodbc.org/) web-site and @odbc.lj). This approach looks promising because it allows us to write only one back-end, instead of one per RDBMS. Since most RDBMS already provide ODBC drivers, this could greatly simplify development. Unfortunately, the Unix implementation of ODBC was not mature enough at the time we looked at it, a situation we expect will change in the next year or so. At that point we will need to re-evaluate it to make sure that such an ODBC interface does not penalize the interface in terms of performance, ease of use, portability among the various Unix versions, etc. ## Java Database Connectivity (JDBC) {#sec:jdbc} Another protocol, the Java database connectivity, is very well-done and supported by just about every RDBMS. The issue with JDBC is that as of today neither S nor R (which are written in C) interfaces cleanly with Java. There are several efforts (some in a quite fairly advanced state) to allow S and R to invoke Java methods. Once this interface is widely available in Splus5x and R we will need to re-visit this issue again and study the performance, usability, etc., of JDBC as a common back-end to the RS-DBI. ## CORBA and a 3-tier Architecture {#sec:corba} Yet another approach is to move the interface to RDBMS out of R and S altogether into a separate system or server that would serve as a proxy between R/S and databases. The communication to this middle-layer proxy could be done through CORBA [@s-corba.98, @corba:siegel.96], Java’s RMI, or some other similar technology. Such a design could be very flexible, but the CORBA facilities both in R and S are not widely available yet, and we do not know whether this will be made available to Splus5 users from MathSoft. Also, my experience with this technology is rather limited. On the other hand, this 3-tier architecture seem to offer the most flexibility to cope with very large distributed databases, not necessarily relational. # Resources {#sec:resources} The latest documentation and software on the RS-DBI was available at www.omegahat.net (link dead now: `http://www.omegahat.net/contrib/RS-DBI/index.html`). The R community has developed interfaces to some databases: [RmSQL](https://cran.r-project.org/src/contrib/Archive/RmSQL/) is an interface to the [mSQL](http://www.Hughes.com.au) database written by Torsten Hothorn; [RPgSQL](http://www.nceas.ucsb.edu/~keitt/R) is an interface to [PostgreSQL](http://www.postgreSQL.org) and was written by Timothy H. Keitt; [RODBC](http://www.stats.ox.ac.uk/pub/bdr) is an interface to ODBC, and it was written by [Michael Lapsley](mailto:mlapsley@sthelier.sghms.ac.uk). (For more details on all these see @R.imp-exp.) The are R and S-Plus interfaces to [MySQL](http://www.mysql.org) that follow the propose RS-DBI API described here; also, there’s an S-Plus interface SOracle @RS-Oracle to [Oracle](http://www.oracle.com) (we expect to have an R implementation soon.) The idea of a common interface to databases has been successfully implemented in Java’s Database Connectivity (JDBC) ([www.javasoft.com](http://www.javasoft.com/products/jdbc/index.html)), in C through the Open Database Connectivity (ODBC) ([www.unixodbc.org](http://www.unixodbc.org/)), in Python’s Database Application Programming Interface ([www.python.org](http://www.python.org)), and in Perl’s Database Interface ([www.cpan.org](http://www.cpan.org)). # Acknowledgements The R/S database interface came about from suggestions, comments, and discussions with [John M. Chambers](mailto:jmc@research.bell-labs.com) and [Duncan Temple Lang](mailto:duncan@research.bell-labs.com) in the context of the Omega Project for Statistical Computing. [Doug Bates](mailto:bates@stat.wisc.edu) and [Saikat DebRoy](mailto:saikat@stat.wisc.edu) ported (and greatly improved) the first MySQL implementation to R. # The S Version 4 Definitions The following code is meant to serve as a detailed description of the R/S to database interface. We decided to use S4 (instead of R or S version 3) because its clean syntax help us to describe easily the classes and methods that form the RS-DBI, and also to convey the inter-class relationships. ```R ## Define all the classes and methods to be used by an ## implementation of the RS-DataBase Interface. Mostly, ## these classes are virtual and each driver should extend ## them to provide the actual implementation. ## Class: dbManager ## This class identifies the DataBase Management System ## (Oracle, MySQL, Informix, PostgreSQL, etc.) setClass("dbManager", VIRTUAL) setGeneric("load", def = function(dbMgr,...) standardGeneric("load") ) setGeneric("unload", def = function(dbMgr,...) standardGeneric("unload") ) setGeneric("getVersion", def = function(dbMgr,...) standardGeneric("getVersion") ) ## Class: dbConnections ## This class captures a connection to a database instance. setClass("dbConnection", VIRTUAL) setGeneric("dbConnection", def = function(dbMgr, ...) standardGeneric("dbConnection") ) setGeneric("dbConnect", def = function(dbMgr, ...) standardGeneric("dbConnect") ) setGeneric("dbExecStatement", def = function(con, statement, ...) standardGeneric("dbExecStatement") ) setGeneric("dbExec", def = function(con, statement, ...) standardGeneric("dbExec") ) setGeneric("getResultSet", def = function(con, ..) standardGeneric("getResultSet") ) setGeneric("commit", def = function(con, ...) standardGeneric("commit") ) setGeneric("rollback", def = function(con, ...) standardGeneric("rollback") ) setGeneric("callProc", def = function(con, ...) standardGeneric("callProc") ) setMethod("close", signature = list(con="dbConnection", type="missing"), def = function(con, type) NULL ) ## Class: dbResult ## This is a base class for arbitrary results from the RDBMS ## (INSERT, UPDATE, DELETE). SELECTs (and SELECT-like) ## statements produce "dbResultSet" objects, which extend ## dbResult. setClass("dbResult", VIRTUAL) setMethod("close", signature = list(con="dbResult", type="missing"), def = function(con, type) NULL ) ## Class: dbResultSet ## Note that we define a resultSet as the result of a ## SELECT SQL statement. setClass("dbResultSet", "dbResult") setGeneric("fetch", def = function(resultSet,n,...) standardGeneric("fetch") ) setGeneric("hasCompleted", def = function(object, ...) standardGeneric("hasCompleted") ) setGeneric("getException", def = function(object, ...) standardGeneric("getException") ) setGeneric("getDBconnection", def = function(object, ...) standardGeneric("getDBconnection") ) setGeneric("setDataMappings", def = function(resultSet, ...) standardGeneric("setDataMappings") ) setGeneric("getFields", def = function(object, table, dbname, ...) standardGeneric("getFields") ) setGeneric("getStatement", def = function(object, ...) standardGeneric("getStatement") ) setGeneric("getRowsAffected", def = function(object, ...) standardGeneric("getRowsAffected") ) setGeneric("getRowCount", def = function(object, ...) standardGeneric("getRowCount") ) setGeneric("getNullOk", def = function(object, ...) standardGeneric("getNullOk") ) ## Meta-data: setGeneric("getInfo", def = function(object, ...) standardGeneric("getInfo") ) setGeneric("describe", def = function(object, verbose=F, ...) standardGeneric("describe") ) setGeneric("getCurrentDatabase", def = function(object, ...) standardGeneric("getCurrentDatabase") ) setGeneric("getDatabases", def = function(object, ...) standardGeneric("getDatabases") ) setGeneric("getTables", def = function(object, dbname, ...) standardGeneric("getTables") ) setGeneric("getTableFields", def = function(object, table, dbname, ...) standardGeneric("getTableFields") ) setGeneric("getTableIndices", def = function(object, table, dbname, ...) standardGeneric("getTableIndices") ) ``` [^2]: A virtual class allows us to group classes that share some common functionality, e.g., the virtual class “`dbConnection`” groups all the connection implementations by Informix, Ingres, DB/2, Oracle, etc. Although the details will vary from one RDBMS to another, the defining characteristic of these objects is what a virtual class captures. R and S version 3 do not explicitly define virtual classes, but they can easily implement the idea through inheritance. [^3]: The term “database” is sometimes (confusingly) used both to denote the RDBMS, such as Oracle, MySQL, and also to denote a particular database instance under a RDBMS, such as “opto” or “sales” databases under the same RDBMS. DBI/vignettes/biblio.bib0000644000176200001440000001771513027447303014614 0ustar liggesusers@string{jcgs="Journal of Computational and Graphical Statistics"} @inproceedings{s-corba.98, author = "Chambers, John M. and Hansen, Mark H. and James, David A. and Temple Lang, Duncan", title = "Distributed Computing with Data: A CORBA-based Approach", booktitle = "Computing Science and Statistics", year = 1998, organization = "Inteface Foundation of North America" } @book{S.88, author = "Becker, R. A. and Chambers, J. M. and Wilks, A. R", year = "1988", title = "The New S Language", publisher = "Wadsworth", address = "Pacific Grove, California" } @book{S.92, editor = "Chambers, J. M. and Hastie, T.", year = 1992, title = "Statistical Models in S", publisher = "Wadsworth", address = "Pacific Grove, California" } @book{S4, author = "Chambers, J. M.", title = "Programming with Data: A Guide to the S Language", publisher = "Springer", address = "New York", year = 1998 } @article{R.96, author = "Ihaka, Ross and Gentleman, Robert", title = "R: A Language for Data Analysis and Graphics", journal = jcgs, volume = 5, number = 3, year = 1996, pages = "299-314" } @book{corba:siegel.96, author = "Siegel, Jon", title = "CORBA Fundamentals and Programming", publisher = "Wiley", address = "New York", year = 1996 } @book{pvm, title = "PVM: Parallel Virtual Machine. A User's Guide and Tutorial for Networked Parallel Computing", author="Geist, A. and Beguelin, A. and Dongarra, J. and Jiang, W. and Mancheck, R. and Sunderam, V.", year = 1994, publisher = "MIT Press", address = "Cambridge, MA" } @manual{splus, title = "S-PLUS Software Documentation", key = "S-PLUS", organization = "StatSci Division of MathSoft Inc.", note = "Version 3.3", year = 1995, address = "Seattle, WA", } @book{tierney.90, author = "Tierney, Luke", year = 1990, title = "LISP-STAT: An Object-Oriented Environment for Statistical Computing and Dynamic Graphics", publisher = "Wiley", address = "New York" } @article{tierney.96, author = "Tierney, Luke", title = "Recent Development and Future Directions in {LispStat}", journal = jcgs, volume = 5, number = 3, year = 1996, pages = "250-262" } @article{odbc.lj, author = "Harvey, Peter", title = "{Open Database Connectivity}", journal = "{Linux Journal}", year = 1999, volume = "Nov.", number = 67, pages = "68-72" } @article{duncan2000, author = "Temple Lang, Duncan", title = "{The Omegahat Environment: New Possibilities for Statistical Computing}", journal = jcgs, volume = "to appear", year = 2000, number = "" } @manual{sql92, title = "{X/Open CAE Specification: SQL and RDA}", organization = "X/Open Company Ltd.", address = "Reading, UK", year = 1994 } @book{MySQL, author = "DuBois, Paul", title = "{MySQL}", publisher = "New Riders Publishing", year = 2000 } @manual{R.ext, title = "Writing {R} Extensions", organization = "{R} Development Core Team", note = "Version 1.2.1 (2001-01-15)", year = 2001 } @manual{R.imp-exp, title = "{R} Data Import/Export", organization = "R-Development Core Team", note = "Version 1.2.1 (2001-01-15)", year = 2001 } @manual{R-dbms, title = "Using Relational Database Systems with {R}", organization = "R-Developemt Core Team", note = "Draft", year = 2000 } @manual{bates.mysql, title = "Using Relational Database Systems with {R}", organization = "R-Developemt Core Team", note = "Draft", year = 2000 } @techreport{proxyDBMS, author = "James, David A.", title = "Proxy Database Object in the S Language", institution = "Bell Labs, Lucent Technologies", year = "In preparation" } @techreport{RS-DBI, author = "James, David A.", title = "A Common Interface to Relational Database Management Sysmtems from {R} and {S} --- A Proposal", institution = "Bell Labs, Lucent Technologies", year = "2000", address = "www.omegahat.org" } @techreport{RS-MySQL, author = "James, David A.", title = "An {R}/{S} Interface to the {MySQL} Database", institution = "Bell Labs, Lucent Technologies", year = "2001", address = "www.omegahat.org" } @techreport{RS-Oracle, author = "James, David A.", title = "An {R}/{S} Interface to the {Oracle} Database", institution = "Bell Labs, Lucent Technologies", year = "In preparation", address = "www.omegahat.org" } @manual{r-data-imp:2001, author = {R Development Core Team}, title = {R Data Import/Export}, year = {2001}, address = {\url{http://www.r-project.org}} } @manual{mysql:2000, author = "Axmark, David and Widenius, Michael and Cole, Jeremy and DuBois, Paul", title = {MySQL Reference Manual}, year = {2001}, address = {\url{http://www.mysql.com/documentation/mysql}} } @manual{jdbc:2000, author = "Ellis, Jon and Ho, Linda and Fisher, Maydene", title = {JDBC 3.0 Specification}, organization = {Sun Microsystems, Inc}, year = {2000}, address = {\url{http://java.sun.com/Download4}} } @article{using-data:2001, author = "Ripley, Brian D.", title = {Using Databases with {R}}, journal = {R {N}ews}, year = {2001}, month = {January}, volume = {1}, number = {1}, pages = {18--20}, address = {\url{http://www.r-project.org/doc/Rnews/}} } @Manual{odbc:2001, title = {Microsoft {ODBC}}, organization = {Microsoft Inc}, address = {\url{http://www.microsoft.com/data/odbc/}}, year = 2001 } @Book{PerlDBI:2000, author = "Descartes, Alligator and Bunce, Tim", title = {Programming the {P}erl {DBI}}, publisher = {O'Reilly}, year = 2000 } @Book{Reese:2000, author = "Reese, George", title = {Database Programming with {JDBC} and {J}ava}, publisher = {O'Reilly}, year = 2000, edition = {second} } @book{Xopen-sql, author = {X/Open Company Ltd.}, title = {X/Open SQL and RDA Specification}, publisher = {X/Open Company Ltd.}, year = 1994 } @book{mysql-dubois, author = "DuBois, Paul", title = {MySQL}, publisher = {New Riders}, year = 2000 } @techreport{data-management:1991, author = "Chambers, John M.", title = {Data Management in {S}}, institution = {Bell Labs, Lucent Technologies}, year = 1991 } @techreport{database-classes:1999, author = "Chambers, John M.", title = {Database Classes}, institution = {Bell Labs, Lucent Technologies}, year = 1998 } @inproceedings{R-dcom, author = "Neuwirth, Erich and Baier, Thomas", title = {Embedding {R} in Standard Software, and the other way around}, organization = {Vienna University of Technology}, year = 2001, booktitle = {Proceedings of the Distributed Statistical Computing 2001 Workshop}, address = {\url{http://www.ci.tuwien.ac.at/Conferences/DSC-2001}} } @inproceedings{R-tcltk, author = "Dalgaard, Peter", title = {The {R}-{T}cl/{T}k Interface}, organization = {Vienna University of Technology}, year = 2001, booktitle = {Proceedings of the Distributed Statistical Computing 2001 Workshop}, address = {\url{http://www.ci.tuwien.ac.at/Conferences/DSC-2001}} } @inproceedings{duncan-dsc2001, author = "Temple Lang, Duncan", title = {Embedding {S} in Other Languages and Environments}, organization = {Vienna University of Technology}, year = 2001, booktitle = {Proceedings of the Distributed Statistical Computing 2001 Workshop}, address = {\url{http://www.ci.tuwien.ac.at/Conferences/DSC-2001}} } @inproceedings{BDR-RMR, author = "Ripley, B. D. and Ripley, R. M.", title = {Applications of {R} Clients and Servers}, organization = {Vienna University of Technology}, year = 2001, booktitle = {Proceedings of the Distributed Statistical Computing 2001 Workshop}, address = {\url{http://www.ci.tuwien.ac.at/Conferences/DSC-2001}} } @inproceedings{rsdbi-dsc2001, author = "Hothorn, Torsten and James, David A. and Ripley, Brian D.", title = {{R}/{S} Interfaces to Databases}, organization = {Vienna University of Technology}, year = 2001, booktitle = {Proceedings of the Distributed Statistical Computing 2001 Workshop}, address = {\url{http://www.ci.tuwien.ac.at/Conferences/DSC-2001}} } DBI/README.md0000644000176200001440000001754013027447303012141 0ustar liggesusers# DBI [![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) [![CRAN_Status_Badge](http://www.r-pkg.org/badges/version/DBI)](https://cran.r-project.org/package=DBI) 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 * extract results/output from statements * error/exception handling * information (meta-data) from database objects * transaction management (optional) DBI separates the connectivity to the DBMS into a "front-end" and a "back-end". Applications use only the exposed "front-end" API. The facilities that communicate with specific DBMSs (SQLite, MySQL, PostgreSQL, MonetDB, etc.) are provided by "drivers" (other packages) that get invoked automatically through S4 methods. The following example illustrates some of the DBI capabilities: ```R library(DBI) # Create an ephemeral in-memory RSQLite database con <- dbConnect(RSQLite::SQLite(), dbname = ":memory:") dbListTables(con) dbWriteTable(con, "mtcars", mtcars) dbListTables(con) dbListFields(con, "mtcars") dbReadTable(con, "mtcars") # You can fetch all results: res <- dbSendQuery(con, "SELECT * FROM mtcars WHERE cyl = 4") dbFetch(res) dbClearResult(res) # Or a chunk at a time res <- dbSendQuery(con, "SELECT * FROM mtcars WHERE cyl = 4") while(!dbHasCompleted(res)){ chunk <- dbFetch(res, n = 5) print(nrow(chunk)) } dbClearResult(res) dbDisconnect(con) ``` To install DBI: * Get the released version from CRAN: `install.packages("DBI")` * Get the development version from github: `devtools::install_github("rstats-db/DBI")` Discussions associated with DBI and related database packages take place on [R-SIG-DB](https://stat.ethz.ch/mailman/listinfo/r-sig-db). ## Class structure There are four main DBI classes. Three which are each extended by individual database backends: * `DBIObject`: a common base class for all DBI. * `DBIDriver`: a base class representing overall DBMS properties. Typically generator functions instantiate the driver objects like `RSQLite()`, `RPostgreSQL()`, `RMySQL()` etc. * `DBIConnection`: represents a connection to a specific database * `DBIResult`: the result of a DBMS query or statement. All classes are _virtual_: they cannot be instantiated directly and instead must be subclassed. ## History 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 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. Within the R community, there were quite a number of people that showed interest on defining a common interface to databases, but only a few folks actually provided code/suggestions/etc. (Tim Keitt was most active with the dbi/PostgreSQL packages --- he also was considering what he called "proxy" objects, which was reminiscent of what Duncan had been doing). Kurt Hornick, Vincent Carey, Robert Gentleman, and others provided suggestions/comments/support for the DBI definition. By around 2003, the DBI was more or less implemented as it is today. I'm sure I'll forget some (most should be in the THANKS sections of the various packages), but the names that come to my mind at this moment are Jake Luciani (ROracle), Don MacQueen and other early ROracle users (super helpful), Doug Bates and his student Saikat DebRoy for RMySQL, Fei Chen (at the time a student of Prof. Ripley) also contributed to RMySQL, Tim Keitt (working on an early S3 interface to PostgrSQL), Torsten Hothorn (worked with mSQL and also MySQL), Prof. Ripley working/extending the RODBC package, in addition to John Chambers and Duncan Temple-Lang who provided very important comments and suggestions. Actually, the real impetus behind the DBI was always to do distributed statistical computing --- *not* to provide a yet-another import/export mechanism --- and this perspective was driven by John and Duncan's vision and work on inter-system computing, COM, CORBA, etc. I'm not sure many of us really appreciated (even now) the full extent of those ideas and concepts. Just like in other languages (C's ODBC, Java's JDBC, Perl's DBI/DBD, Python dbapi), R/S DBI was meant to unify the interfacing to RDBMS so that R/S applications could be developed on top of the DBI and not be hard coded to any one relation database. The interface I tried to follow the closest was the Python's DBAPI --- I haven't worked on this topic for a while, but I still feel Python's DBAPI is the cleanest and most relevant for the S language. DBI/MD50000644000176200001440000001225613070027747011175 0ustar liggesusers71fa75364857594d7efac226caa7d5f5 *DESCRIPTION 6a00e3dad05303053dc3c1c5aa2ab5e5 *NAMESPACE d92b5f5a01a2c1d64c47e17b19d23d47 *NEWS.md b59c3fcacbb6cc23346a5c50e4dae8ea *R/ANSI.R 7d26a199b7a6d9458031792d5d6b24e1 *R/DBConnection.R 51afc93dc90e7b56af03d9884a4570e5 *R/DBDriver.R 457c8422b7fcb9172f307c3b9794116a *R/DBI-package.R 72c1ca45c29ac2907b7c40064d06f2b9 *R/DBObject.R 3c718d4051e3972dc5b1f1634894727e *R/DBResult.R d378b9fd446e9ddba97dc9a981534f20 *R/data-types.R bc6c9fe4bb4df6fa6391285695bc29d9 *R/data.R f2c0b10c1983eef6358384390a9ca9fe *R/deprecated.R fe1b2df9042ccf14f76f1eb981938db7 *R/hidden.R 9e334728c2868d16a35ada101548f082 *R/interpolate.R c5e29f904ce44585edd3ee3c3037678d *R/quote.R ef367483cb2eb34b90a0a945531d2dfe *R/rownames.R 8015290f238c1a7cd823dfac0421f138 *R/table-create.R 27d35bbc520590a097872c6c8209811d *R/table-insert.R 02ac159467a987a786924a05d2eae815 *R/table.R 6ab5bab7b1f749a17a27f21835bbd367 *R/transactions.R 4a3f6f7e39108075adc36f7b30849bd4 *R/util.R d2e3065bb7e64fe2d155242c948a1447 *README.md 90a986100e634513f96635c1b83aa3b4 *build/vignette.rds 20045f48d6152af7f31bfe9f4cc98ef1 *inst/doc/DBI-1.Rmd 53eac3bfcfdb934f214431cc4633a597 *inst/doc/DBI-1.html f65e1d2d58e032ebc2c5a30c71183730 *inst/doc/DBI-proposal.Rmd fddf17d54a5409a67756ba04ef86d77e *inst/doc/DBI-proposal.html b1b80e1e252186276d12b45cffbdfb8c *inst/doc/backend.R 32f6b8f5fe00e0af63b8b5d3ac8a7b8a *inst/doc/backend.Rmd 4d01729c775f246c7eab632c6b44591c *inst/doc/backend.html 873a57b456faec81c3403e05d5c525db *inst/doc/spec.R 6979f3a457872954b3c1fd19f5347c36 *inst/doc/spec.Rmd a49941b8bd6641425ace46ab283069b9 *inst/doc/spec.html 4354c7d19733ce8222bb9c06ef0db20d *man/ANSI.Rd 6467d2cf2457c1913c7a4e3bca0153d4 *man/DBI-package.Rd 13acb78f11958ac166e7db8b77e12ae2 *man/DBIConnection-class.Rd 4a6c65ecc7d1cdb309141ac429ed0765 *man/DBIDriver-class.Rd ff5df5387b4fcb3e714561b349e13678 *man/DBIObject-class.Rd bb362e79bda0e8ef1eb57ba6333fb18d *man/DBIResult-class.Rd bc3ad493e5de59e3ee5f8839147b373c *man/SQL.Rd 90b8bf63661ee497f1b439c60e735105 *man/Table.Rd 25a07f339e8a16a430f5714cc51d56f4 *man/dbBind.Rd bfbf90e3a638c248c9de19ff713dc553 *man/dbCallProc.Rd c680559e39944922222dc5e4b55a4f59 *man/dbClearResult.Rd 186f79c0753429904fc7acb4491598c5 *man/dbColumnInfo.Rd e3809d532f65a420866e47418bb068e8 *man/dbConnect.Rd 8bf9648b8d0824662e6250eae7dbf422 *man/dbDataType.Rd 3fdf7a09820f197285b0c814d6eab7c0 *man/dbDisconnect.Rd 7805775a4bdbb7157166af52f96dbfde *man/dbDriver.Rd d5bd39724f97bf1ca5dcafb3a820c5cc *man/dbExecute.Rd 3b92893138532e0402737bb0f7b4fb6d *man/dbExistsTable.Rd b03e61f714a6d1a7bb4736f03967f149 *man/dbFetch.Rd 600709b1318e882e99b98e90fa8ba7e7 *man/dbGetDBIVersion.Rd 02500809110e60de9447f27fe69ceb57 *man/dbGetException.Rd 8133cba92923ccc85d3196b22f8f9d73 *man/dbGetInfo.Rd 54e537aea1d1517221256a9c80f22a3e *man/dbGetQuery.Rd 877ba2521e852911eb63c0254c35ba00 *man/dbGetRowCount.Rd eed07d4aad545e4fd9f8e887570d2af8 *man/dbGetRowsAffected.Rd 53367cbe914fd5e9f4fef2974d5da4b4 *man/dbGetStatement.Rd 3455f678f4994719e07eecd67edd9bab *man/dbHasCompleted.Rd 811eaa527cb43592e150fe0e822dfdce *man/dbIsValid.Rd 92ee20559033f9d8d3d49af09f23e7d2 *man/dbListConnections.Rd 7f7d799c746538ac36fffbce8245982b *man/dbListFields.Rd cb7f6ee23793b291d9da5ca66719b0aa *man/dbListResults.Rd e03693ec13836639b6948b4ca0e25ff6 *man/dbListTables.Rd 22639a498b49684e54a12277239e69e9 *man/dbQuoteIdentifier.Rd 1b7ac1794bb5ce42320734d4a5629c43 *man/dbQuoteString.Rd 4a02a15586a89992de0ff785ee6f7a0f *man/dbReadTable.Rd 3799d9cfd0bec10b35bb551d0c6c5c36 *man/dbRemoveTable.Rd 6ab10029d4f036d6c49fd27aebc06ae3 *man/dbSendQuery.Rd a1b8fd63093640ccdea9e95c9315e14e *man/dbSendStatement.Rd efc9ad682c86a680573d3f05e3b88abb *man/dbSetDataMappings.Rd a0ef26392dd11c31bec66a51818c8e56 *man/dbWithTransaction.Rd 399d000719e7e983a7c4295106ff2b29 *man/dbWriteTable.Rd fbfd1a62198973eb85eaf3549db7c397 *man/hidden_aliases.Rd 86be48ec351e8312603f64e3e8974996 *man/make.db.names.Rd ac2a113fca77eb940072865e98652505 *man/print.list.pairs.Rd 5b606a6756e9d24b3341551233fb7e84 *man/rownames.Rd 41318f75c2642dc2663cbabe50e4f111 *man/sqlAppendTable.Rd ed265703fb18a5b015080eaf25dca041 *man/sqlCreateTable.Rd 7a34ae1f8e0f1ad0a810893017037400 *man/sqlData.Rd 6efeff3adea08d3b061b50d60528f0cd *man/sqlInterpolate.Rd 9a5a1d367aa34d84801abf10a3b69585 *man/sqlParseVariables.Rd 0f842d6c555b79afffd1ee9b5aa1d27d *man/transactions.Rd a4fe1ddf5f03bdcb9a22c2674a266e9e *tests/testthat.R a0e8f9eb80974345f902b315a0409281 *tests/testthat/helper-dummy.R a5c7fc57a17838c7ca22d66c0d96dc61 *tests/testthat/test-data-type.R 79a8ac66aaad56217df2abcbe6dc74fd *tests/testthat/test-interpolate.R 58549e35e48e852f047d0c6296608ac2 *tests/testthat/test-methods.R cd76b7ebb292ae81700170150e899418 *tests/testthat/test-quote.R e8afe06a3e597ec1063be9f351b63a6c *tests/testthat/test-quoting.R 936863cb0e7bb14bf6f3e913d28a77d1 *tests/testthat/test-rownames.R 793d64584aa74172076b4d3f3b67bd12 *tests/testthat/test-sql-df.R 20045f48d6152af7f31bfe9f4cc98ef1 *vignettes/DBI-1.Rmd f65e1d2d58e032ebc2c5a30c71183730 *vignettes/DBI-proposal.Rmd 32f6b8f5fe00e0af63b8b5d3ac8a7b8a *vignettes/backend.Rmd c63a631c86125636916478bb0b682e2c *vignettes/biblio.bib 16facd043de5250ab88f5b3badef9ab0 *vignettes/hierarchy.png 6979f3a457872954b3c1fd19f5347c36 *vignettes/spec.Rmd DBI/build/0000755000176200001440000000000013070016501011740 5ustar liggesusersDBI/build/vignette.rds0000644000176200001440000000052113070016501014275 0ustar liggesusersRMO@]hE`yozğV A^vt7!FR8|}32!cς ``Lf@gD'/"~F;t |TY:3%u~fZJ 斯AH*)-sħV(-m` p3L&0]'(QBpFNsi=HYƻSF¯E>j/;QK MR4IM9ܔ%w9p`8/zKa$XsKmXFW*aWEf~+J7^i^Q=e? FDBI/DESCRIPTION0000644000176200001440000000265613070027747012376 0ustar liggesusersPackage: DBI Version: 0.6-1 Date: 2017-04-01 Title: R Database Interface 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. Authors@R: c( person("R Special Interest Group on Databases (R-SIG-DB)", role = "aut"), person("Hadley", "Wickham", role = "aut"), person("Kirill", "Müller", email = "krlmlr+r@mailbox.org", role = c("aut", "cre")) ) Depends: R (>= 2.15.0), methods Suggests: covr, hms, knitr, magrittr, rprojroot, rmarkdown, RSQLite (>= 1.1-2), testthat, xml2 Encoding: UTF-8 License: LGPL (>= 2) URL: http://rstats-db.github.io/DBI URLNote: https://github.com/rstats-db/DBI BugReports: https://github.com/rstats-db/DBI/issues Collate: 'DBObject.R' 'DBDriver.R' 'DBConnection.R' 'ANSI.R' 'DBI-package.R' 'DBResult.R' 'data-types.R' 'data.R' 'deprecated.R' 'hidden.R' 'interpolate.R' 'quote.R' 'rownames.R' 'table-create.R' 'table-insert.R' 'table.R' 'transactions.R' 'util.R' VignetteBuilder: knitr RoxygenNote: 6.0.1 NeedsCompilation: no Packaged: 2017-04-01 21:36:01 UTC; muelleki Author: R Special Interest Group on Databases (R-SIG-DB) [aut], Hadley Wickham [aut], Kirill Müller [aut, cre] Maintainer: Kirill Müller Repository: CRAN Date/Publication: 2017-04-01 22:55:35 UTC DBI/man/0000755000176200001440000000000013070016377011427 5ustar liggesusersDBI/man/dbListResults.Rd0000644000176200001440000000210713055626140014517 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbListResults} \alias{dbListResults} \title{A list of all pending results} \usage{ dbListResults(conn, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{...}{Other parameters passed on to methods.} } \value{ a list. If no results are active, an empty list. If only a single result is active, a list with one element. } \description{ List of \linkS4class{DBIResult} objects currently active on the connection. } \seealso{ Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/dbGetInfo.Rd0000644000176200001440000000535413055626140013564 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBObject.R, R/DBResult.R \name{dbGetInfo} \alias{dbGetInfo} \alias{dbGetInfo} \title{Get DBMS metadata} \usage{ dbGetInfo(dbObj, ...) } \arguments{ \item{dbObj}{An object inheriting from \linkS4class{DBIObject}, i.e. \linkS4class{DBIDriver}, \linkS4class{DBIConnection}, or a \linkS4class{DBIResult}} \item{...}{Other arguments to methods.} } \value{ a named list } \description{ Get DBMS metadata } \section{Implementation notes}{ For \code{DBIDriver} subclasses, this should include the version of the package (\code{driver.version}) and the version of the underlying client library (\code{client.version}). For \code{DBIConnection} objects this should report the version of the DBMS engine (\code{db.version}), database name (\code{dbname}), username, (\code{username}), host (\code{host}), port (\code{port}), etc. It MAY also include any other arguments related to the connection (e.g., thread id, socket or TCP connection type). It MUST NOT include the password. For \code{DBIResult} objects, this should include the statement being executed (\code{statement}), how many rows have been fetched so far (in the case of queries, \code{row.count}), how many rows were affected (deleted, inserted, changed, (\code{rows.affected}), and if the query is complete (\code{has.completed}). The default implementation for \code{DBIResult objects} constructs such a list from the return values of the corresponding methods, \code{\link[=dbGetStatement]{dbGetStatement()}}, \code{\link[=dbGetRowCount]{dbGetRowCount()}}, \code{\link[=dbGetRowsAffected]{dbGetRowsAffected()}}, and \code{\link[=dbHasCompleted]{dbHasCompleted()}}. } \seealso{ Other DBIDriver generics: \code{\link{DBIDriver-class}}, \code{\link{dbConnect}}, \code{\link{dbDataType}}, \code{\link{dbDriver}}, \code{\link{dbIsValid}}, \code{\link{dbListConnections}} Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/dbSendQuery.Rd0000644000176200001440000000651213055626140014145 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbSendQuery} \alias{dbSendQuery} \title{Execute a query on a given database connection} \usage{ dbSendQuery(conn, statement, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{statement}{a character string containing SQL.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbSendQuery()} returns an S4 object that inherits from \linkS4class{DBIResult}. The result set can be used with \code{\link[=dbFetch]{dbFetch()}} to extract records. Once you have finished using a result, make sure to clear it with \code{\link[=dbClearResult]{dbClearResult()}}. An error is raised when issuing a query over a closed or invalid connection, if the syntax of the query is invalid, or if the query is not a non-\code{NA} string. } \description{ The \code{dbSendQuery()} method only submits and synchronously executes the SQL query to the database engine. It does \emph{not} extract any records --- for that you need to use the \code{\link[=dbFetch]{dbFetch()}} method, and then you must call \code{\link[=dbClearResult]{dbClearResult()}} when you finish fetching the records you need. For interactive use, you should almost always prefer \code{\link[=dbGetQuery]{dbGetQuery()}}. } \details{ This method is for \code{SELECT} queries only. Some backends may support data manipulation queries through this method for compatibility reasons. However, callers are strongly encouraged to use \code{\link[=dbSendStatement]{dbSendStatement()}} for data manipulation statements. The query is submitted to the database server and the DBMS executes it, possibly generating vast amounts of data. Where these data live is driver-specific: some drivers may choose to leave the output on the server and transfer them piecemeal to R, others may transfer all the data to the client -- but not necessarily to the memory that R manages. See individual drivers' \code{dbSendQuery()} documentation for details. } \section{Specification}{ No warnings occur under normal conditions. When done, the DBIResult object must be cleared with a call to \code{\link[=dbClearResult]{dbClearResult()}}. Failure to clear the result set leads to a warning when the connection is closed. If the backend supports only one open result set per connection, issuing a second query invalidates an already open result set and raises a warning. The newly opened result set is valid and must be cleared with \code{dbClearResult()}. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars) rs <- dbSendQuery(con, "SELECT * FROM mtcars WHERE cyl = 4;") dbFetch(rs) dbClearResult(rs) dbDisconnect(con) } \seealso{ For updates: \code{\link[=dbSendStatement]{dbSendStatement()}} and \code{\link[=dbExecute]{dbExecute()}}. Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/dbListConnections.Rd0000644000176200001440000000133713055626140015344 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBDriver.R \name{dbListConnections} \alias{dbListConnections} \title{List currently open connections} \usage{ dbListConnections(drv, ...) } \arguments{ \item{drv}{A object inheriting from \linkS4class{DBIDriver}} \item{...}{Other arguments passed on to methods.} } \value{ a list } \description{ Drivers that implement only a single connections MUST return a list containing a single element. If no connection are open, methods MUST return an empty list. } \seealso{ Other DBIDriver generics: \code{\link{DBIDriver-class}}, \code{\link{dbConnect}}, \code{\link{dbDataType}}, \code{\link{dbDriver}}, \code{\link{dbGetInfo}}, \code{\link{dbIsValid}} } DBI/man/dbIsValid.Rd0000644000176200001440000000540213055626140013556 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBObject.R \name{dbIsValid} \alias{dbIsValid} \title{Is this DBMS object still valid?} \usage{ dbIsValid(dbObj, ...) } \arguments{ \item{dbObj}{An object inheriting from \linkS4class{DBIObject}, i.e. \linkS4class{DBIDriver}, \linkS4class{DBIConnection}, or a \linkS4class{DBIResult}} \item{...}{Other arguments to methods.} } \value{ \code{dbIsValid()} returns a logical scalar, \code{TRUE} if the object specified by \code{dbObj} is valid, \code{FALSE} otherwise. A \linkS4class{DBIConnection} object is initially valid, and becomes invalid after disconnecting with \code{\link[=dbDisconnect]{dbDisconnect()}}. A \linkS4class{DBIResult} object is valid after a call to \code{\link[=dbSendQuery]{dbSendQuery()}}, and stays valid even after all rows have been fetched; only clearing it with \code{\link[=dbClearResult]{dbClearResult()}} invalidates it. A \linkS4class{DBIResult} object is also valid after a call to \code{\link[=dbSendStatement]{dbSendStatement()}}, and stays valid after querying the number of rows affected; only clearing it with \code{\link[=dbClearResult]{dbClearResult()}} invalidates it. If the connection to the database system is dropped (e.g., due to connectivity problems, server failure, etc.), \code{dbIsValid()} should return \code{FALSE}. This is not tested automatically. } \description{ This generic tests whether a database object is still valid (i.e. it hasn't been disconnected or cleared). } \examples{ dbIsValid(RSQLite::SQLite()) con <- dbConnect(RSQLite::SQLite(), ":memory:") dbIsValid(con) rs <- dbSendQuery(con, "SELECT 1") dbIsValid(rs) dbClearResult(rs) dbIsValid(rs) dbDisconnect(con) dbIsValid(con) } \seealso{ Other DBIDriver generics: \code{\link{DBIDriver-class}}, \code{\link{dbConnect}}, \code{\link{dbDataType}}, \code{\link{dbDriver}}, \code{\link{dbGetInfo}}, \code{\link{dbListConnections}} Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/ANSI.Rd0000644000176200001440000000046013054310030012431 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/ANSI.R \name{ANSI} \alias{ANSI} \title{A dummy DBI connector that simulates ANSI-SQL compliance} \usage{ ANSI() } \description{ A dummy DBI connector that simulates ANSI-SQL compliance } \examples{ ANSI() } \keyword{internal} DBI/man/DBIDriver-class.Rd0000644000176200001440000000146713054310030014564 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBDriver.R \docType{class} \name{DBIDriver-class} \alias{DBIDriver-class} \title{DBIDriver class} \description{ Base class for all DBMS drivers (e.g., RSQLite, MySQL, PostgreSQL). The virtual class \code{DBIDriver} defines the operations for creating connections and defining data type mappings. Actual driver classes, for instance \code{RPgSQL}, \code{RMySQL}, etc. implement these operations in a DBMS-specific manner. } \seealso{ Other DBI classes: \code{\link{DBIConnection-class}}, \code{\link{DBIObject-class}}, \code{\link{DBIResult-class}} Other DBIDriver generics: \code{\link{dbConnect}}, \code{\link{dbDataType}}, \code{\link{dbDriver}}, \code{\link{dbGetInfo}}, \code{\link{dbIsValid}}, \code{\link{dbListConnections}} } DBI/man/hidden_aliases.Rd0000644000176200001440000000731013055221643014650 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBDriver.R, R/DBConnection.R, R/ANSI.R, % R/DBResult.R, R/data.R, R/deprecated.R, R/hidden.R, R/interpolate.R, % R/quote.R, R/table-create.R, R/table-insert.R, R/table.R, R/transactions.R \docType{methods} \name{dbDriver,character-method} \alias{dbDriver,character-method} \alias{show,DBIDriver-method} \alias{dbDataType,DBIObject-method} \alias{show,DBIConnection-method} \alias{dbSendStatement,DBIConnection,character-method} \alias{dbGetQuery,DBIConnection,character-method} \alias{dbExecute,DBIConnection,character-method} \alias{dbReadTable,DBIConnection,character-method} \alias{show,AnsiConnection-method} \alias{show,DBIResult-method} \alias{dbFetch,DBIResult-method} \alias{dbGetInfo,DBIResult-method} \alias{sqlData,DBIConnection-method} \alias{make.db.names,DBIObject,character-method} \alias{isSQLKeyword,DBIObject,character-method} \alias{SQLKeywords,DBIObject-method} \alias{SQLKeywords,missing-method} \alias{hidden_aliases} \alias{sqlInterpolate,DBIConnection-method} \alias{sqlParseVariables,DBIConnection-method} \alias{show,SQL-method} \alias{dbQuoteIdentifier,DBIConnection,character-method} \alias{dbQuoteIdentifier,DBIConnection,SQL-method} \alias{dbQuoteString,DBIConnection,character-method} \alias{dbQuoteString,DBIConnection,SQL-method} \alias{sqlCreateTable,DBIConnection-method} \alias{sqlAppendTable,DBIConnection-method} \alias{dbQuoteIdentifier,DBIConnection,Table-method} \alias{show,Table-method} \alias{dbWithTransaction,DBIConnection-method} \title{Internal page for hidden aliases} \usage{ \S4method{dbDriver}{character}(drvName, ...) \S4method{show}{DBIDriver}(object) \S4method{dbDataType}{DBIObject}(dbObj, obj, ...) \S4method{show}{DBIConnection}(object) \S4method{dbSendStatement}{DBIConnection,character}(conn, statement, ...) \S4method{dbGetQuery}{DBIConnection,character}(conn, statement, ...) \S4method{dbExecute}{DBIConnection,character}(conn, statement, ...) \S4method{dbReadTable}{DBIConnection,character}(conn, name, ..., row.names = NA, check.names = TRUE) \S4method{show}{AnsiConnection}(object) \S4method{show}{DBIResult}(object) \S4method{dbFetch}{DBIResult}(res, n = -1, ...) \S4method{dbGetInfo}{DBIResult}(dbObj, ...) \S4method{sqlData}{DBIConnection}(con, value, row.names = NA, ...) \S4method{make.db.names}{DBIObject,character}(dbObj, snames, keywords = .SQL92Keywords, unique = TRUE, allow.keywords = TRUE, ...) \S4method{isSQLKeyword}{DBIObject,character}(dbObj, name, keywords = .SQL92Keywords, case = c("lower", "upper", "any")[3], ...) \S4method{SQLKeywords}{DBIObject}(dbObj, ...) \S4method{SQLKeywords}{missing}(dbObj, ...) \S4method{sqlInterpolate}{DBIConnection}(conn, sql, ..., .dots = list()) \S4method{sqlParseVariables}{DBIConnection}(conn, sql, ...) \S4method{show}{SQL}(object) \S4method{dbQuoteIdentifier}{DBIConnection,character}(conn, x, ...) \S4method{dbQuoteIdentifier}{DBIConnection,SQL}(conn, x, ...) \S4method{dbQuoteString}{DBIConnection,character}(conn, x, ...) \S4method{dbQuoteString}{DBIConnection,SQL}(conn, x, ...) \S4method{sqlCreateTable}{DBIConnection}(con, table, fields, row.names = NA, temporary = FALSE, ...) \S4method{sqlAppendTable}{DBIConnection}(con, table, values, row.names = NA, ...) \S4method{dbQuoteIdentifier}{DBIConnection,Table}(conn, x, ...) \S4method{show}{Table}(object) \S4method{dbWithTransaction}{DBIConnection}(conn, code) } \arguments{ \item{object}{Object to display} \item{conn, x}{Connection and Table used when escaping.} \item{object}{Object to display} \item{object}{Object to display} \item{object}{Table object to print} } \description{ For S4 methods that require a documentation entry but only clutter the index. } \keyword{internal} DBI/man/dbFetch.Rd0000644000176200001440000001135013070016377013255 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \name{dbFetch} \alias{dbFetch} \alias{fetch} \title{Fetch records from a previously executed query} \usage{ dbFetch(res, n = -1, ...) fetch(res, n = -1, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}, created by \code{\link[=dbSendQuery]{dbSendQuery()}}.} \item{n}{maximum number of records to retrieve per fetch. Use \code{n = -1} or \code{n = Inf} to retrieve all pending records. Some implementations may recognize other special values.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbFetch()} always returns a \link{data.frame} with as many rows as records were fetched and as many columns as fields in the result set, even if the result is a single value or has one or zero rows. An attempt to fetch from a closed result set raises an error. If the \code{n} argument is not an atomic whole number greater or equal to -1 or Inf, an error is raised, but a subsequent call to \code{dbFetch()} with proper \code{n} argument succeeds. Calling \code{dbFetch()} on a result set from a data manipulation query created by \code{\link[=dbSendStatement]{dbSendStatement()}} can be fetched and return an empty data frame, with a warning. } \description{ Fetch the next \code{n} elements (rows) from the result set and return them as a data.frame. } \details{ \code{fetch()} is provided for compatibility with older DBI clients - for all new code you are strongly encouraged to use \code{dbFetch()}. The default implementation for \code{dbFetch()} calls \code{fetch()} so that it is compatible with existing code. Modern backends should implement for \code{dbFetch()} only. } \section{Specification}{ Fetching multi-row queries with one or more columns be default returns the entire result. Multi-row queries can also be fetched progressively by passing a whole number (\link{integer} or \link{numeric}) as the \code{n} argument. A value of \link{Inf} for the \code{n} argument is supported and also returns the full result. If more rows than available are fetched, the result is returned in full without warning. If fewer rows than requested are returned, further fetches will return a data frame with zero rows. If zero rows are fetched, the columns of the data frame are still fully typed. Fetching fewer rows than available is permitted, no warning is issued when clearing the result set. The column types of the returned data frame depend on the data returned: \itemize{ \item \link{integer} for integer values between -2^31 and 2^31 - 1 \item \link{numeric} for numbers with a fractional component \item \link{logical} for Boolean values (some backends may return an integer) \item \link{character} for text \item lists of \link{raw} for blobs (with \code{NULL} entries for SQL NULL values) \item coercible using \code{\link[=as.Date]{as.Date()}} for dates (also applies to the return value of the SQL function \code{current_date}) \item coercible using \code{\link[hms:as.hms]{hms::as.hms()}} for times (also applies to the return value of the SQL function \code{current_time}) \item coercible using \code{\link[=as.POSIXct]{as.POSIXct()}} for timestamps (also applies to the return value of the SQL function \code{current_timestamp}) \item \link{NA} for SQL \code{NULL} values } If dates and timestamps are supported by the backend, the following R types are used: \itemize{ \item \link{Date} for dates (also applies to the return value of the SQL function \code{current_date}) \item \link{POSIXct} for timestamps (also applies to the return value of the SQL function \code{current_timestamp}) } R has no built-in type with lossless support for the full range of 64-bit or larger integers. Here, the following rules apply: \itemize{ \item Values are returned as numeric \item Conversion to character always returns a lossless decimal representation of the data } } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars) # Fetch all results rs <- dbSendQuery(con, "SELECT * FROM mtcars WHERE cyl = 4") dbFetch(rs) dbClearResult(rs) # Fetch in chunks rs <- dbSendQuery(con, "SELECT * FROM mtcars") while (!dbHasCompleted(rs)) { chunk <- dbFetch(rs, 10) print(nrow(chunk)) } dbClearResult(rs) dbDisconnect(con) } \seealso{ Close the result set with \code{\link[=dbClearResult]{dbClearResult()}} as soon as you finish retrieving the records you want. Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/sqlParseVariables.Rd0000644000176200001440000000313213055626140015336 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/interpolate.R \name{sqlParseVariables} \alias{sqlParseVariables} \alias{sqlCommentSpec} \alias{sqlQuoteSpec} \alias{sqlParseVariablesImpl} \title{Parse interpolated variables from SQL.} \usage{ sqlParseVariables(conn, sql, ...) sqlCommentSpec(start, end, endRequired) sqlQuoteSpec(start, end, escape = "", doubleEscape = TRUE) sqlParseVariablesImpl(sql, quotes, comments) } \arguments{ \item{sql}{SQL to parse (a character string)} \item{start, end}{Start and end characters for quotes and comments} \item{endRequired}{Is the ending character of a comment required?} \item{escape}{What character can be used to escape quoting characters? Defaults to \code{""}, i.e. nothing.} \item{doubleEscape}{Can quoting characters be escaped by doubling them? Defaults to \code{TRUE}.} \item{quotes}{A list of \code{QuoteSpec} calls defining the quoting specification.} \item{comments}{A list of \code{CommentSpec} calls defining the commenting specification.} } \description{ If you're implementing a backend that uses non-ANSI quoting or commenting rules, you'll need to implement a method for \code{sqlParseVariables} that calls \code{sqlParseVariablesImpl} with the appropriate quote and comment specifications. } \examples{ # Use [] for quoting and no comments sqlParseVariablesImpl("[?a]", list(sqlQuoteSpec("[", "]", "\\\\", FALSE)), list() ) # Standard quotes, use # for commenting sqlParseVariablesImpl("# ?a\\n?b", list(sqlQuoteSpec("'", "'"), sqlQuoteSpec('"', '"')), list(sqlCommentSpec("#", "\\n", FALSE)) ) } \keyword{internal} DBI/man/dbColumnInfo.Rd0000644000176200001440000000270313055626140014275 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \name{dbColumnInfo} \alias{dbColumnInfo} \title{Information about result types} \usage{ dbColumnInfo(res, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}.} \item{...}{Other arguments passed on to methods.} } \value{ A data.frame with one row per output field in \code{res}. Methods MUST include \code{name}, \code{field.type} (the SQL type), and \code{data.type} (the R data type) columns, and MAY contain other database specific information like scale and precision or whether the field can store \code{NULL}s. } \description{ Produces a data.frame that describes the output of a query. The data.frame should have as many rows as there are output fields in the result set, and each column in the data.frame should describe an aspect of the result set field (field name, type, etc.) } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") rs <- dbSendQuery(con, "SELECT 1 AS a, 2 AS b") dbColumnInfo(rs) dbFetch(rs) dbClearResult(rs) dbDisconnect(con) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/sqlInterpolate.Rd0000644000176200001440000000262313055626140014725 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/interpolate.R \name{sqlInterpolate} \alias{sqlInterpolate} \title{Safely interpolate values into an SQL string} \usage{ sqlInterpolate(conn, sql, ..., .dots = list()) } \arguments{ \item{conn}{A database connection.} \item{sql}{A SQL string containing variables to interpolate. Variables must start with a question mark and can be any valid R identifier, i.e. it must start with a letter or \code{.}, and be followed by a letter, digit, \code{.} or \code{_}.} \item{..., .dots}{Named values (for \code{...}) or a named list (for \code{.dots}) to interpolate into a string. All strings will be first escaped with \code{\link[=dbQuoteString]{dbQuoteString()}} prior to interpolation to protect against SQL injection attacks.} } \description{ Safely interpolate values into an SQL string } \section{Backend authors}{ If you are implementing an SQL backend with non-ANSI quoting rules, you'll need to implement a method for \code{\link[=sqlParseVariables]{sqlParseVariables()}}. Failure to do so does not expose you to SQL injection attacks, but will (rarely) result in errors matching supplied and interpolated variables. } \examples{ sql <- "SELECT * FROM X WHERE name = ?name" sqlInterpolate(ANSI(), sql, name = "Hadley") # This is safe because the single quote has been double escaped sqlInterpolate(ANSI(), sql, name = "H'); DROP TABLE--;") } DBI/man/dbListFields.Rd0000644000176200001440000000235613055626140014272 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbListFields} \alias{dbListFields} \title{List field names of a remote table} \usage{ dbListFields(conn, name, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{name}{a character string with the name of the remote table.} \item{...}{Other parameters passed on to methods.} } \value{ a character vector } \description{ List field names of a remote table } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars) dbListFields(con, "mtcars") dbDisconnect(con) } \seealso{ \code{\link[=dbColumnInfo]{dbColumnInfo()}} to get the type of the fields. Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/DBIConnection-class.Rd0000644000176200001440000000241113055221643015432 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \docType{class} \name{DBIConnection-class} \alias{DBIConnection-class} \title{DBIConnection class} \description{ This virtual class encapsulates the connection to a DBMS, and it provides access to dynamic queries, result sets, DBMS session management (transactions), etc. } \section{Implementation note}{ Individual drivers are free to implement single or multiple simultaneous connections. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") con dbDisconnect(con) \dontrun{ con <- dbConnect(RPostgreSQL::PostgreSQL(), "username", "passsword") con dbDisconnect(con) } } \seealso{ Other DBI classes: \code{\link{DBIDriver-class}}, \code{\link{DBIObject-class}}, \code{\link{DBIResult-class}} Other DBIConnection generics: \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/print.list.pairs.Rd0000644000176200001440000000101513054310030015117 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/util.R \name{print.list.pairs} \alias{print.list.pairs} \title{Print a list of pairs.} \usage{ \method{print}{list.pairs}(x, ...) } \arguments{ \item{x}{a list of key, value pairs} \item{...}{additional arguments to be passed to \code{cat}} } \value{ the (invisible) value of x. } \description{ DEPRECATED, do not use. Use \code{\link[base:summary]{base::summary()}} to print output of \code{\link[=dbGetInfo]{dbGetInfo()}}. } \keyword{internal} DBI/man/dbHasCompleted.Rd0000644000176200001440000000430513055626140014574 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \name{dbHasCompleted} \alias{dbHasCompleted} \title{Completion status} \usage{ dbHasCompleted(res, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbHasCompleted()} returns a logical scalar. For a query initiated by \code{\link[=dbSendQuery]{dbSendQuery()}} with non-empty result set, \code{dbHasCompleted()} returns \code{FALSE} initially and \code{TRUE} after calling \code{\link[=dbFetch]{dbFetch()}} without limit. For a query initiated by \code{\link[=dbSendStatement]{dbSendStatement()}}, \code{dbHasCompleted()} always returns \code{TRUE}. Attempting to query completion status for a result set cleared with \code{\link[=dbClearResult]{dbClearResult()}} gives an error. } \description{ This method returns if the operation has completed. A \code{SELECT} query is completed if all rows have been fetched. A data manipulation statement is always completed. } \section{Specification}{ The completion status for a query is only guaranteed to be set to \code{FALSE} after attempting to fetch past the end of the entire result. Therefore, for a query with an empty result set, the initial return value is unspecified, but the result value is \code{TRUE} after trying to fetch only one row. Similarly, for a query with a result set of length n, the return value is unspecified after fetching n rows, but the result value is \code{TRUE} after trying to fetch only one more row. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars) rs <- dbSendQuery(con, "SELECT * FROM mtcars") dbHasCompleted(rs) ret1 <- dbFetch(rs, 10) dbHasCompleted(rs) ret2 <- dbFetch(rs) dbHasCompleted(rs) dbClearResult(rs) dbDisconnect(con) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/dbSendStatement.Rd0000644000176200001440000000617513055626140015011 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbSendStatement} \alias{dbSendStatement} \title{Execute a data manipulation statement on a given database connection} \usage{ dbSendStatement(conn, statement, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{statement}{a character string containing SQL.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbSendStatement()} returns an S4 object that inherits from \linkS4class{DBIResult}. The result set can be used with \code{\link[=dbGetRowsAffected]{dbGetRowsAffected()}} to determine the number of rows affected by the query. Once you have finished using a result, make sure to clear it with \code{\link[=dbClearResult]{dbClearResult()}}. An error is raised when issuing a statement over a closed or invalid connection, if the syntax of the statement is invalid, or if the statement is not a non-\code{NA} string. } \description{ The \code{dbSendStatement()} method only submits and synchronously executes the SQL data manipulation statement (e.g., \code{UPDATE}, \code{DELETE}, \code{INSERT INTO}, \code{DROP TABLE}, ...) to the database engine. To query the number of affected rows, call \code{\link[=dbGetRowsAffected]{dbGetRowsAffected()}} on the returned result object. You must also call \code{\link[=dbClearResult]{dbClearResult()}} after that. For interactive use, you should almost always prefer \code{\link[=dbExecute]{dbExecute()}}. } \details{ \code{\link[=dbSendStatement]{dbSendStatement()}} comes with a default implementation that simply forwards to \code{\link[=dbSendQuery]{dbSendQuery()}}, to support backends that only implement the latter. } \section{Specification}{ No warnings occur under normal conditions. When done, the DBIResult object must be cleared with a call to \code{\link[=dbClearResult]{dbClearResult()}}. Failure to clear the result set leads to a warning when the connection is closed. If the backend supports only one open result set per connection, issuing a second query invalidates an already open result set and raises a warning. The newly opened result set is valid and must be cleared with \code{dbClearResult()}. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "cars", head(cars, 3)) rs <- dbSendStatement(con, "INSERT INTO cars (speed, dist) VALUES (1, 1), (2, 2), (3, 3);") dbHasCompleted(rs) dbGetRowsAffected(rs) dbClearResult(rs) dbReadTable(con, "cars") # there are now 6 rows dbDisconnect(con) } \seealso{ For queries: \code{\link[=dbSendQuery]{dbSendQuery()}} and \code{\link[=dbGetQuery]{dbGetQuery()}}. Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbWriteTable}} } DBI/man/dbDriver.Rd0000644000176200001440000000414613055626140013462 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBDriver.R \name{dbDriver} \alias{dbDriver} \alias{dbUnloadDriver} \title{Load and unload database drivers} \usage{ dbDriver(drvName, ...) dbUnloadDriver(drv, ...) } \arguments{ \item{drvName}{character name of the driver to instantiate.} \item{...}{any other arguments are passed to the driver \code{drvName}.} \item{drv}{an object that inherits from \code{DBIDriver} as created by \code{dbDriver}.} } \value{ In the case of \code{dbDriver}, an driver object whose class extends \code{DBIDriver}. This object may be used to create connections to the actual DBMS engine. In the case of \code{dbUnloadDriver}, a logical indicating whether the operation succeeded or not. } \description{ These methods are deprecated, please consult the documentation of the individual backends for the construction of driver instances. \code{dbDriver()} is a helper method used to create an new driver object given the name of a database or the corresponding R package. It works through convention: all DBI-extending packages should provide an exported object with the same name as the package. \code{dbDriver()} just looks for this object in the right places: if you know what database you are connecting to, you should call the function directly. \code{dbUnloadDriver()} is not implemented for modern backends. } \details{ The client part of the database communication is initialized (typically dynamically loading C code, etc.) but note that connecting to the database engine itself needs to be done through calls to \code{dbConnect}. } \examples{ # Create a RSQLite driver with a string d <- dbDriver("SQLite") d # But better, access the object directly RSQLite::SQLite() } \seealso{ Other DBIDriver generics: \code{\link{DBIDriver-class}}, \code{\link{dbConnect}}, \code{\link{dbDataType}}, \code{\link{dbGetInfo}}, \code{\link{dbIsValid}}, \code{\link{dbListConnections}} Other DBIDriver generics: \code{\link{DBIDriver-class}}, \code{\link{dbConnect}}, \code{\link{dbDataType}}, \code{\link{dbGetInfo}}, \code{\link{dbIsValid}}, \code{\link{dbListConnections}} } DBI/man/dbExecute.Rd0000644000176200001440000000425013055626140013625 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbExecute} \alias{dbExecute} \title{Execute an update statement, query number of rows affected, and then close result set} \usage{ dbExecute(conn, statement, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{statement}{a character string containing SQL.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbExecute()} always returns a scalar numeric that specifies the number of rows affected by the statement. An error is raised when issuing a statement over a closed or invalid connection, if the syntax of the statement is invalid, or if the statement is not a non-\code{NA} string. } \description{ Executes a statement and returns the number of rows affected. \code{dbExecute()} comes with a default implementation (which should work with most backends) that calls \code{\link[=dbSendStatement]{dbSendStatement()}}, then \code{\link[=dbGetRowsAffected]{dbGetRowsAffected()}}, ensuring that the result is always free-d by \code{\link[=dbClearResult]{dbClearResult()}}. } \section{Implementation notes}{ Subclasses should override this method only if they provide some sort of performance optimization. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "cars", head(cars, 3)) dbReadTable(con, "cars") # there are 3 rows dbExecute(con, "INSERT INTO cars (speed, dist) VALUES (1, 1), (2, 2), (3, 3);") dbReadTable(con, "cars") # there are now 6 rows dbDisconnect(con) } \seealso{ For queries: \code{\link[=dbSendQuery]{dbSendQuery()}} and \code{\link[=dbGetQuery]{dbGetQuery()}}. Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/DBIResult-class.Rd0000644000176200001440000000233413055221643014615 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \docType{class} \name{DBIResult-class} \alias{DBIResult-class} \title{DBIResult class} \description{ This virtual class describes the result and state of execution of a DBMS statement (any statement, query or non-query). The result set keeps track of whether the statement produces output how many rows were affected by the operation, how many rows have been fetched (if statement is a query), whether there are more rows to fetch, etc. } \section{Implementation notes}{ Individual drivers are free to allow single or multiple active results per connection. The default show method displays a summary of the query using other DBI generics. } \seealso{ Other DBI classes: \code{\link{DBIConnection-class}}, \code{\link{DBIDriver-class}}, \code{\link{DBIObject-class}} Other DBIResult generics: \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/dbGetRowsAffected.Rd0000644000176200001440000000316613055626140015244 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \name{dbGetRowsAffected} \alias{dbGetRowsAffected} \title{The number of rows affected} \usage{ dbGetRowsAffected(res, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbGetRowsAffected()} returns a scalar number (integer or numeric), the number of rows affected by a data manipulation statement issued with \code{\link[=dbSendStatement]{dbSendStatement()}}. The value is available directly after the call and does not change after calling \code{\link[=dbFetch]{dbFetch()}}. For queries issued with \code{\link[=dbSendQuery]{dbSendQuery()}}, zero is returned before and after the call to \code{dbFetch()}. Attempting to get the rows affected for a result set cleared with \code{\link[=dbClearResult]{dbClearResult()}} gives an error. } \description{ This method returns the number of rows that were added, deleted, or updated by a data manipulation statement. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars) rs <- dbSendStatement(con, "DELETE FROM mtcars") dbGetRowsAffected(rs) nrow(mtcars) dbClearResult(rs) dbDisconnect(con) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/sqlCreateTable.Rd0000644000176200001440000000366313054310030014602 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/table-create.R \name{sqlCreateTable} \alias{sqlCreateTable} \title{Create a simple table} \usage{ sqlCreateTable(con, table, fields, row.names = NA, temporary = FALSE, ...) } \arguments{ \item{con}{A database connection.} \item{table}{Name of the table. Escaped with \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}.} \item{fields}{Either a character vector or a data frame. A named character vector: Names are column names, values are types. Names are escaped with \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}. Field types are unescaped. A data frame: field types are generated using \code{\link[=dbDataType]{dbDataType()}}.} \item{row.names}{Either \code{TRUE}, \code{FALSE}, \code{NA} or a string. If \code{TRUE}, always translate row names to a column called "row_names". If \code{FALSE}, never translate row names. If \code{NA}, translate rownames only if they're a character vector. A string is equivalent to \code{TRUE}, but allows you to override the default name. For backward compatibility, \code{NULL} is equivalent to \code{FALSE}.} \item{temporary}{If \code{TRUE}, will generate a temporary table statement.} \item{...}{Other arguments used by individual methods.} } \description{ Exposes interface to simple \code{CREATE TABLE} commands. The default method is ANSI SQL 99 compliant. This method is mostly useful for backend implementers. } \section{DBI-backends}{ If you implement one method (i.e. for strings or data frames), you need to implement both, otherwise the S4 dispatch rules will be ambiguous and will generate an error on every call. } \examples{ sqlCreateTable(ANSI(), "my-table", c(a = "integer", b = "text")) sqlCreateTable(ANSI(), "my-table", iris) # By default, character row names are converted to a row_names colum sqlCreateTable(ANSI(), "mtcars", mtcars[, 1:5]) sqlCreateTable(ANSI(), "mtcars", mtcars[, 1:5], row.names = FALSE) } DBI/man/Table.Rd0000644000176200001440000000105713054310030012731 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/table.R \docType{class} \name{Table-class} \alias{Table-class} \alias{Table} \title{Refer to a table nested in a hierarchy (e.g. within a schema)} \usage{ Table(...) } \arguments{ \item{...}{Components of the hierarchy, e.g. \code{schema}, \code{table}, or \code{cluster}, \code{catalog}, \code{schema}, \code{table}. For more on these concepts, see \url{http://stackoverflow.com/questions/7022755/}} } \description{ Refer to a table nested in a hierarchy (e.g. within a schema) } DBI/man/dbRemoveTable.Rd0000644000176200001440000000454213060005002014414 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbRemoveTable} \alias{dbRemoveTable} \title{Remove a table from the database} \usage{ dbRemoveTable(conn, name, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{name}{A character string specifying a DBMS table name.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbRemoveTable()} returns \code{TRUE}, invisibly. If the table does not exist, an error is raised. An attempt to remove a view with this function may result in an error. An error is raised if \code{name} cannot be processed with \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}} or if this results in a non-scalar. } \description{ Remove a remote table (e.g., created by \code{\link[=dbWriteTable]{dbWriteTable()}}) from the database. } \section{Specification}{ A table removed by \code{dbRemoveTable()} doesn't appear in the list of tables returned by \code{\link[=dbListTables]{dbListTables()}}, and \code{\link[=dbExistsTable]{dbExistsTable()}} returns \code{FALSE}. The removal propagates immediately to other connections to the same database. This function can also be used to remove a temporary table. The \code{name} argument is processed as follows, to support databases that allow non-syntactic names for their objects: \itemize{ \item If an unquoted table name as string: \code{dbRemoveTable()} will do the quoting, perhaps by calling \code{dbQuoteIdentifier(conn, x = name)} \item If the result of a call to \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}: no more quoting is done } } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbExistsTable(con, "iris") dbWriteTable(con, "iris", iris) dbExistsTable(con, "iris") dbRemoveTable(con, "iris") dbExistsTable(con, "iris") dbDisconnect(con) } \seealso{ Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/dbGetException.Rd0000644000176200001440000000207313055626140014622 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbGetException} \alias{dbGetException} \title{Get DBMS exceptions} \usage{ dbGetException(conn, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{...}{Other parameters passed on to methods.} } \value{ a list with elements \code{errorNum} (an integer error number) and \code{errorMsg} (a character string) describing the last error in the connection \code{conn}. } \description{ Get DBMS exceptions } \seealso{ Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/DBIObject-class.Rd0000644000176200001440000000310313054310030014524 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBObject.R \docType{class} \name{DBIObject-class} \alias{DBIObject-class} \title{DBIObject class} \description{ Base class for all other DBI classes (e.g., drivers, connections). This is a virtual Class: No objects may be created from it. } \details{ More generally, the DBI defines a very small set of classes and generics that allows users and applications access DBMS with a common interface. The virtual classes are \code{DBIDriver} that individual drivers extend, \code{DBIConnection} that represent instances of DBMS connections, and \code{DBIResult} that represent the result of a DBMS statement. These three classes extend the basic class of \code{DBIObject}, which serves as the root or parent of the class hierarchy. } \section{Implementation notes}{ An implementation MUST provide methods for the following generics: \itemize{ \item \code{\link[=dbGetInfo]{dbGetInfo()}}. } It MAY also provide methods for: \itemize{ \item \code{\link[=summary]{summary()}}. Print a concise description of the object. The default method invokes \code{dbGetInfo(dbObj)} and prints the name-value pairs one per line. Individual implementations may tailor this appropriately. } } \examples{ drv <- RSQLite::SQLite() con <- dbConnect(drv) rs <- dbSendQuery(con, "SELECT 1") is(drv, "DBIObject") ## True is(con, "DBIObject") ## True is(rs, "DBIObject") dbClearResult(rs) dbDisconnect(con) } \seealso{ Other DBI classes: \code{\link{DBIConnection-class}}, \code{\link{DBIDriver-class}}, \code{\link{DBIResult-class}} } DBI/man/make.db.names.Rd0000644000176200001440000000656513054310030014316 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/deprecated.R \name{make.db.names} \alias{make.db.names} \alias{SQLKeywords} \alias{isSQLKeyword} \alias{make.db.names.default} \alias{isSQLKeyword} \alias{isSQLKeyword.default} \title{Make R identifiers into legal SQL identifiers} \usage{ make.db.names(dbObj, snames, keywords = .SQL92Keywords, unique = TRUE, allow.keywords = TRUE, ...) make.db.names.default(snames, keywords = .SQL92Keywords, unique = TRUE, allow.keywords = TRUE) isSQLKeyword(dbObj, name, keywords = .SQL92Keywords, case = c("lower", "upper", "any")[3], ...) isSQLKeyword.default(name, keywords = .SQL92Keywords, case = c("lower", "upper", "any")[3]) } \arguments{ \item{dbObj}{any DBI object (e.g., \code{DBIDriver}).} \item{snames}{a character vector of R identifiers (symbols) from which we need to make SQL identifiers.} \item{keywords}{a character vector with SQL keywords, by default it's \code{.SQL92Keywords} defined by the DBI.} \item{unique}{logical describing whether the resulting set of SQL names should be unique. Its default is \code{TRUE}. Following the SQL 92 standard, uniqueness of SQL identifiers is determined regardless of whether letters are upper or lower case.} \item{allow.keywords}{logical describing whether SQL keywords should be allowed in the resulting set of SQL names. Its default is \code{TRUE}} \item{\dots}{any other argument are passed to the driver implementation.} \item{name}{a character vector with database identifier candidates we need to determine whether they are legal SQL identifiers or not.} \item{case}{a character string specifying whether to make the comparison as lower case, upper case, or any of the two. it defaults to \code{any}.} } \value{ \code{make.db.names} returns a character vector of legal SQL identifiers corresponding to its \code{snames} argument. \code{SQLKeywords} returns a character vector of all known keywords for the database-engine associated with \code{dbObj}. \code{isSQLKeyword} returns a logical vector parallel to \code{name}. } \description{ These methods are DEPRECATED. Please use \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}} (or possibly \code{\link[=dbQuoteString]{dbQuoteString()}}) instead. } \details{ The algorithm in \code{make.db.names} first invokes \code{make.names} and then replaces each occurrence of a dot \code{.} by an underscore \code{_}. If \code{allow.keywords} is \code{FALSE} and identifiers collide with SQL keywords, a small integer is appended to the identifier in the form of \code{"_n"}. The set of SQL keywords is stored in the character vector \code{.SQL92Keywords} and reflects the SQL ANSI/ISO standard as documented in "X/Open SQL and RDA", 1994, ISBN 1-872630-68-8. Users can easily override or update this vector. } \section{Bugs}{ The current mapping is not guaranteed to be fully reversible: some SQL identifiers that get mapped into R identifiers with \code{make.names} and then back to SQL with \code{\link[=make.db.names]{make.db.names()}} will not be equal to the original SQL identifiers (e.g., compound SQL identifiers of the form \code{username.tablename} will loose the dot ``.''). } \references{ The set of SQL keywords is stored in the character vector \code{.SQL92Keywords} and reflects the SQL ANSI/ISO standard as documented in "X/Open SQL and RDA", 1994, ISBN 1-872630-68-8. Users can easily override or update this vector. } DBI/man/dbConnect.Rd0000644000176200001440000000447713057745024013634 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBDriver.R \name{dbConnect} \alias{dbConnect} \title{Create a connection to a DBMS} \usage{ dbConnect(drv, ...) } \arguments{ \item{drv}{an object that inherits from \linkS4class{DBIDriver}, or an existing \linkS4class{DBIConnection} object (in order to clone an existing connection).} \item{...}{authentication arguments needed by the DBMS instance; these typically include \code{user}, \code{password}, \code{host}, \code{port}, \code{dbname}, etc. For details see the appropriate \code{DBIDriver}.} } \value{ \code{dbConnect()} returns an S4 object that inherits from \linkS4class{DBIConnection}. This object is used to communicate with the database engine. } \description{ Connect to a DBMS going through the appropriate authentication procedure. Some implementations may allow you to have multiple connections open, so you may invoke this function repeatedly assigning its output to different objects. The authentication mechanism is left unspecified, so check the documentation of individual drivers for details. } \section{Specification}{ DBI recommends using the following argument names for authentication parameters, with \code{NULL} default: \itemize{ \item \code{user} for the user name (default: current user) \item \code{password} for the password \item \code{host} for the host name (default: local connection) \item \code{port} for the port number (default: local connection) \item \code{dbname} for the name of the database on the host, or the database file name } The defaults should provide reasonable behavior, in particular a local connection for \code{host = NULL}. For some DBMS (e.g., PostgreSQL), this is different to a TCP/IP connection to \code{localhost}. } \examples{ # SQLite only needs a path to the database. (Here, ":memory:" is a special # path that creates an in-memory database.) Other database drivers # will require more details (like user, password, host, port, etc.) con <- dbConnect(RSQLite::SQLite(), ":memory:") con dbListTables(con) dbDisconnect(con) } \seealso{ \code{\link[=dbDisconnect]{dbDisconnect()}} to disconnect from a database. Other DBIDriver generics: \code{\link{DBIDriver-class}}, \code{\link{dbDataType}}, \code{\link{dbDriver}}, \code{\link{dbGetInfo}}, \code{\link{dbIsValid}}, \code{\link{dbListConnections}} } DBI/man/dbExistsTable.Rd0000644000176200001440000000432513060005002014435 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbExistsTable} \alias{dbExistsTable} \title{Does a table exist?} \usage{ dbExistsTable(conn, name, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{name}{A character string specifying a DBMS table name.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbExistsTable()} returns a logical scalar, \code{TRUE} if the table or view specified by the \code{name} argument exists, \code{FALSE} otherwise. This includes temporary tables if supported by the database. An error is raised if \code{name} cannot be processed with \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}} or if this results in a non-scalar. } \description{ Returns if a table given by name exists in the database. } \section{Additional arguments}{ TBD: \code{temporary = NA} This must be provided as named argument. See the "Specification" section for details on their usage. } \section{Specification}{ The \code{name} argument is processed as follows, to support databases that allow non-syntactic names for their objects: \itemize{ \item If an unquoted table name as string: \code{dbExistsTable()} will do the quoting, perhaps by calling \code{dbQuoteIdentifier(conn, x = name)} \item If the result of a call to \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}: no more quoting is done } For all tables listed by \code{\link[=dbListTables]{dbListTables()}}, \code{dbExistsTable()} returns \code{TRUE}. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbExistsTable(con, "iris") dbWriteTable(con, "iris", iris) dbExistsTable(con, "iris") dbDisconnect(con) } \seealso{ Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/dbWriteTable.Rd0000644000176200001440000001270613070016377014274 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbWriteTable} \alias{dbWriteTable} \title{Copy data frames to database tables} \usage{ dbWriteTable(conn, name, value, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{name}{A character string specifying the unquoted DBMS table name, or the result of a call to \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}.} \item{value}{a \link{data.frame} (or coercible to data.frame).} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbWriteTable()} returns \code{TRUE}, invisibly. If the table exists (and both \code{append} and \code{overwrite} arguments are unset), an error is raised; the remote table remains unchanged. An error is also raised if \code{name} cannot be processed with \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}} or if this results in a non-scalar. Invalid values for the additional arguments \code{row.names}, \code{overwrite}, \code{append}, \code{field.types}, and \code{temporary} (non-scalars, unsupported data types, \code{NA}, incompatible values) also raise an error. } \description{ Writes, overwrites or appends a data frame to a database table, optionally converting row names to a column and specifying SQL data types for fields. } \section{Additional arguments}{ The following arguments are not part of the \code{dbWriteTable()} generic (to improve compatibility across backends) but are part of the DBI specification: \itemize{ \item \code{row.names} (default: \code{NA}) \item \code{overwrite} (default: \code{FALSE}) \item \code{append} (default: \code{FALSE}) \item \code{field.types} (default: \code{NULL}) \item \code{temporary} (default: \code{FALSE}) } They must be provided as named arguments. See the "Specification" and "Value" sections for details on their usage. } \section{Specification}{ The \code{name} argument is processed as follows, to support databases that allow non-syntactic names for their objects: \itemize{ \item If an unquoted table name as string: \code{dbWriteTable()} will do the quoting, perhaps by calling \code{dbQuoteIdentifier(conn, x = name)} \item If the result of a call to \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}: no more quoting is done } If the \code{overwrite} argument is \code{TRUE}, an existing table of the same name will be overwritten. This argument doesn't change behavior if the table does not exist yet. If the \code{append} argument is \code{TRUE}, the rows in an existing table are preserved, and the new data are appended. If the table doesn't exist yet, it is created. If the \code{temporary} argument is \code{TRUE}, the table is not available in a second connection and is gone after reconnecting. Not all backends support this argument. A regular, non-temporary table is visible in a second connection and after reconnecting to the database. SQL keywords can be used freely in table names, column names, and data. Quotes, commas, and spaces can also be used in the data, and, if the database supports non-syntactic identifiers, also for table names and column names. The following data types must be supported at least, and be read identically with \code{\link[=dbReadTable]{dbReadTable()}}: \itemize{ \item integer \item numeric (also with \code{Inf} and \code{NaN} values, the latter are translated to \code{NA}) \item logical \item \code{NA} as NULL \item 64-bit values (using \code{"bigint"} as field type) \item character (in both UTF-8 and native encodings) \item factor (returned as character) \item list of raw (if supported by the database) \item date (if supported by the database; returned as \code{Date}) \item time (if supported by the database; returned as objects that inherit from \code{difftime}) \item timestamp (if supported by the database; returned as \code{POSIXlt} with time zone support) } The interpretation of \link{rownames} depends on the \code{row.names} argument, see \code{\link[=sqlRownamesToColumn]{sqlRownamesToColumn()}} for details: \itemize{ \item If \code{FALSE}, row names are ignored. \item If \code{TRUE}, row names are converted to a column named "row_names", even if the input data frame only has natural row names from 1 to \code{nrow(...)}. \item If \code{NA}, a column named "row_names" is created if the data has custom row names, no extra column is created in the case of natural row names. \item If a string, this specifies the name of the column in the remote table that contains the row names, even if the input data frame only has natural row names. } } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars[1:5, ]) dbReadTable(con, "mtcars") dbWriteTable(con, "mtcars", mtcars[6:10, ], append = TRUE) dbReadTable(con, "mtcars") dbWriteTable(con, "mtcars", mtcars[1:10, ], overwrite = TRUE) dbReadTable(con, "mtcars") # No row names dbWriteTable(con, "mtcars", mtcars[1:10, ], overwrite = TRUE, row.names = FALSE) dbReadTable(con, "mtcars") } \seealso{ Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}} } DBI/man/dbListTables.Rd0000644000176200001440000000337013060005002014253 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbListTables} \alias{dbListTables} \title{List remote tables} \usage{ dbListTables(conn, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbListTables()} returns a character vector that enumerates all tables and views in the database. Tables added with \code{\link[=dbWriteTable]{dbWriteTable()}} are part of the list, including temporary tables if supported by the database. As soon a table is removed from the database, it is also removed from the list of database tables. The returned names are suitable for quoting with \code{dbQuoteIdentifier()}. } \description{ Returns the unquoted names of remote tables accessible through this connection. This should, where possible, include temporary tables, and views. } \section{Additional arguments}{ TBD: \code{temporary = NA} This must be provided as named argument. See the "Specification" section for details on their usage. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbListTables(con) dbWriteTable(con, "mtcars", mtcars) dbListTables(con) dbDisconnect(con) } \seealso{ Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/dbGetQuery.Rd0000644000176200001440000000571213055626140013774 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbGetQuery} \alias{dbGetQuery} \title{Send query, retrieve results and then clear result set} \usage{ dbGetQuery(conn, statement, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{statement}{a character string containing SQL.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbGetQuery()} always returns a \link{data.frame} with as many rows as records were fetched and as many columns as fields in the result set, even if the result is a single value or has one or zero rows. An error is raised when issuing a query over a closed or invalid connection, if the syntax of the query is invalid, or if the query is not a non-\code{NA} string. If the \code{n} argument is not an atomic whole number greater or equal to -1 or Inf, an error is raised, but a subsequent call to \code{dbGetQuery()} with proper \code{n} argument succeeds. } \description{ Returns the result of a query as a data frame. \code{dbGetQuery()} comes with a default implementation (which should work with most backends) that calls \code{\link[=dbSendQuery]{dbSendQuery()}}, then \code{\link[=dbFetch]{dbFetch()}}, ensuring that the result is always free-d by \code{\link[=dbClearResult]{dbClearResult()}}. } \details{ This method is for \code{SELECT} queries only. Some backends may support data manipulation statements through this method for compatibility reasons. However, callers are strongly advised to use \code{\link[=dbExecute]{dbExecute()}} for data manipulation statements. } \section{Implementation notes}{ Subclasses should override this method only if they provide some sort of performance optimization. } \section{Specification}{ Fetching multi-row queries with one or more columns be default returns the entire result. A value of \link{Inf} for the \code{n} argument is supported and also returns the full result. If more rows than available are fetched, the result is returned in full without warning. If zero rows are fetched, the columns of the data frame are still fully typed. Fetching fewer rows than available is permitted, no warning is issued. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars) dbGetQuery(con, "SELECT * FROM mtcars") dbDisconnect(con) } \seealso{ For updates: \code{\link[=dbSendStatement]{dbSendStatement()}} and \code{\link[=dbExecute]{dbExecute()}}. Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/dbGetStatement.Rd0000644000176200001440000000256113055626140014632 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \name{dbGetStatement} \alias{dbGetStatement} \title{Get the statement associated with a result set} \usage{ dbGetStatement(res, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbGetStatement()} returns a string, the query used in either \code{\link[=dbSendQuery]{dbSendQuery()}} or \code{\link[=dbSendStatement]{dbSendStatement()}}. Attempting to query the statement for a result set cleared with \code{\link[=dbClearResult]{dbClearResult()}} gives an error. } \description{ Returns the statement that was passed to \code{\link[=dbSendQuery]{dbSendQuery()}} or \code{\link[=dbSendStatement]{dbSendStatement()}}. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars) rs <- dbSendQuery(con, "SELECT * FROM mtcars") dbGetStatement(rs) dbClearResult(rs) dbDisconnect(con) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/dbDisconnect.Rd0000644000176200001440000000256513055626140014323 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbDisconnect} \alias{dbDisconnect} \title{Disconnect (close) a connection} \usage{ dbDisconnect(conn, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbDisconnect()} returns \code{TRUE}, invisibly. } \description{ This closes the connection, discards all pending work, and frees resources (e.g., memory, sockets). } \section{Specification}{ A warning is issued on garbage collection when a connection has been released without calling \code{dbDisconnect()}. A warning is issued immediately when calling \code{dbDisconnect()} on an already disconnected connection. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbDisconnect(con) } \seealso{ Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/SQL.Rd0000644000176200001440000000343613055221643012360 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/quote.R \docType{class} \name{SQL} \alias{SQL} \alias{SQL-class} \title{SQL quoting} \usage{ SQL(x) } \arguments{ \item{x}{A character vector to label as being escaped SQL.} \item{...}{Other arguments passed on to methods. Not otherwise used.} } \value{ An object of class \code{SQL}. } \description{ This set of classes and generics make it possible to flexibly deal with SQL escaping needs. By default, any user supplied input to a query should be escaped using either \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}} or \code{\link[=dbQuoteString]{dbQuoteString()}} depending on whether it refers to a table or variable name, or is a literal string. These functions may return an object of the \code{SQL} class, which tells DBI functions that a character string does not need to be escaped anymore, to prevent double escaping. The \code{SQL} class has associated the \code{SQL()} constructor function. } \section{Implementation notes}{ DBI provides default generics for SQL-92 compatible quoting. If the database uses a different convention, you will need to provide your own methods. Note that because of the way that S4 dispatch finds methods and because SQL inherits from character, if you implement (e.g.) a method for \code{dbQuoteString(MyConnection, character)}, you will also need to implement \code{dbQuoteString(MyConnection, SQL)} - this should simply return \code{x} unchanged. } \examples{ dbQuoteIdentifier(ANSI(), "SELECT") dbQuoteString(ANSI(), "SELECT") # SQL vectors are always passed through as is var_name <- SQL("SELECT") var_name dbQuoteIdentifier(ANSI(), var_name) dbQuoteString(ANSI(), var_name) # This mechanism is used to prevent double escaping dbQuoteString(ANSI(), dbQuoteString(ANSI(), "SELECT")) } DBI/man/rownames.Rd0000644000176200001440000000270013055626140013546 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/rownames.R \name{rownames} \alias{rownames} \alias{sqlRownamesToColumn} \alias{sqlColumnToRownames} \title{Convert row names back and forth between columns} \usage{ sqlRownamesToColumn(df, row.names = NA) sqlColumnToRownames(df, row.names = NA) } \arguments{ \item{df}{A data frame} \item{row.names}{Either \code{TRUE}, \code{FALSE}, \code{NA} or a string. If \code{TRUE}, always translate row names to a column called "row_names". If \code{FALSE}, never translate row names. If \code{NA}, translate rownames only if they're a character vector. A string is equivalent to \code{TRUE}, but allows you to override the default name. For backward compatibility, \code{NULL} is equivalent to \code{FALSE}.} } \description{ These functions provide a reasonably automatic way of preserving the row names of data frame during back-and-forth translation to an SQL table. By default, row names will be converted to an explicit column called "row_names", and any query returning a column called "row_names" will have those automatically set as row names. These methods are mostly useful for backend implementers. } \examples{ # If have row names sqlRownamesToColumn(head(mtcars)) sqlRownamesToColumn(head(mtcars), FALSE) sqlRownamesToColumn(head(mtcars), "ROWNAMES") # If don't have sqlRownamesToColumn(head(iris)) sqlRownamesToColumn(head(iris), TRUE) sqlRownamesToColumn(head(iris), "ROWNAMES") } DBI/man/dbGetDBIVersion.Rd0000644000176200001440000000045513054310030014615 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/deprecated.R \name{dbGetDBIVersion} \alias{dbGetDBIVersion} \title{Determine the current version of the package.} \usage{ dbGetDBIVersion() } \description{ Determine the current version of the package. } \keyword{internal} DBI/man/sqlData.Rd0000644000176200001440000000263513055626140013313 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/data.R \name{sqlData} \alias{sqlData} \title{Convert a data frame into form suitable for upload to an SQL database} \usage{ sqlData(con, value, row.names = NA, ...) } \arguments{ \item{con}{A database connection.} \item{value}{A data frame} \item{row.names}{Either \code{TRUE}, \code{FALSE}, \code{NA} or a string. If \code{TRUE}, always translate row names to a column called "row_names". If \code{FALSE}, never translate row names. If \code{NA}, translate rownames only if they're a character vector. A string is equivalent to \code{TRUE}, but allows you to override the default name. For backward compatibility, \code{NULL} is equivalent to \code{FALSE}.} \item{...}{Other arguments used by individual methods.} } \description{ This is a generic method that coerces R objects into vectors suitable for upload to the database. The output will vary a little from method to method depending on whether the main upload device is through a single SQL string or multiple parameterized queries. This method is mostly useful for backend implementers. } \details{ The default method: \itemize{ \item Converts factors to characters \item Quotes all strings \item Converts all columns to strings \item Replaces NA with NULL } } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") sqlData(con, head(iris)) sqlData(con, head(mtcars)) dbDisconnect(con) } DBI/man/transactions.Rd0000644000176200001440000000727013055626140014432 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/transactions.R \name{transactions} \alias{transactions} \alias{dbBegin} \alias{dbCommit} \alias{dbRollback} \title{Begin/commit/rollback SQL transactions} \usage{ dbBegin(conn, ...) dbCommit(conn, ...) dbRollback(conn, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbBegin()}, \code{dbCommit()} and \code{dbRollback()} return \code{TRUE}, invisibly. The implementations are expected to raise an error in case of failure, but this is not tested. In any way, all generics throw an error with a closed connection. In addition, a call to \code{dbCommit()} or \code{dbRollback()} without a prior call to \code{dbBegin()} raises an error. Nested transactions are not supported by DBI, an attempt to call \code{dbBegin()} twice yields an error. } \description{ A transaction encapsulates several SQL statements in an atomic unit. It is initiated with \code{dbBegin()} and either made persistent with \code{dbCommit()} or undone with \code{dbRollback()}. In any case, the DBMS guarantees that either all or none of the statements have a permanent effect. This helps ensuring consistency of write operations to multiple tables. } \details{ Not all database engines implement transaction management, in which case these methods should not be implemented for the specific \linkS4class{DBIConnection} subclass. } \section{Specification}{ Actual support for transactions may vary between backends. A transaction is initiated by a call to \code{dbBegin()} and committed by a call to \code{dbCommit()}. Data written in a transaction must persist after the transaction is committed. For example, a table that is missing when the transaction is started but is created and populated during the transaction must exist and contain the data added there both during and after the transaction, and also in a new connection. A transaction can also be aborted with \code{dbRollback()}. All data written in such a transaction must be removed after the transaction is rolled back. For example, a table that is missing when the transaction is started but is created during the transaction must not exist anymore after the rollback. Disconnection from a connection with an open transaction gives a warning and effectively rolls back the transaction. All data written in such a transaction must be removed after the transaction is rolled back. The behavior is not specified if other arguments are passed to these functions. In particular, \pkg{RSQLite} issues named transactions with support for nesting if the \code{name} argument is set. The transaction isolation level is not specified by DBI. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "cash", data.frame(amount = 100)) dbWriteTable(con, "account", data.frame(amount = 2000)) # All operations are carried out as logical unit: dbBegin(con) withdrawal <- 300 dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal)) dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal)) dbCommit(con) dbReadTable(con, "cash") dbReadTable(con, "account") # Rolling back after detecting negative value on account: dbBegin(con) withdrawal <- 5000 dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal)) dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal)) if (dbReadTable(con, "account")$amount >= 0) { dbCommit(con) } else { dbRollback(con) } dbReadTable(con, "cash") dbReadTable(con, "account") dbDisconnect(con) } \seealso{ Self-contained transactions: \code{\link[=dbWithTransaction]{dbWithTransaction()}} } DBI/man/dbDataType.Rd0000644000176200001440000001010713055626140013734 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBDriver.R \name{dbDataType} \alias{dbDataType} \title{Determine the SQL data type of an object} \usage{ dbDataType(dbObj, obj, ...) } \arguments{ \item{dbObj}{A object inheriting from \linkS4class{DBIDriver} or \linkS4class{DBIConnection}} \item{obj}{An R object whose SQL type we want to determine.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbDataType()} returns the SQL type that corresponds to the \code{obj} argument as a non-empty character string. For data frames, a character vector with one element per column is returned. An error is raised for invalid values for the \code{obj} argument such as a \code{NULL} value. } \description{ Returns an SQL string that describes the SQL data type to be used for an object. The default implementation of this generic determines the SQL type of an R object according to the SQL 92 specification, which may serve as a starting point for driver implementations. DBI also provides an implementation for data.frame which will return a character vector giving the type for each column in the dataframe. } \details{ The data types supported by databases are different than the data types in R, but the mapping between the primitive types is straightforward: \itemize{ \item Any of the many fixed and varying length character types are mapped to character vectors \item Fixed-precision (non-IEEE) numbers are mapped into either numeric or integer vectors. } Notice that many DBMS do not follow IEEE arithmetic, so there are potential problems with under/overflows and loss of precision. } \section{Specification}{ The backend can override the \code{\link[=dbDataType]{dbDataType()}} generic for its driver class. This generic expects an arbitrary object as second argument. To query the values returned by the default implementation, run \code{example(dbDataType, package = "DBI")}. If the backend needs to override this generic, it must accept all basic R data types as its second argument, namely \link{logical}, \link{integer}, \link{numeric}, \link{character}, dates (see \link{Dates}), date-time (see \link{DateTimeClasses}), and \link{difftime}. It also must accept lists of \link{raw} vectors and map them to the BLOB (binary large object) data type, unless the \code{omit_blob_tests} tweak is set to \code{TRUE}. As-is objects (i.e., wrapped by \code{\link[=I]{I()}}) must be supported and return the same results as their unwrapped counterparts. The SQL data type for \link{factor} and \link{ordered} is the same as for character. The behavior for other object types is not specified. All data types returned by \code{dbDataType()} are usable in an SQL statement of the form \code{"CREATE TABLE test (a ...)"}. } \examples{ dbDataType(ANSI(), 1:5) dbDataType(ANSI(), 1) dbDataType(ANSI(), TRUE) dbDataType(ANSI(), Sys.Date()) dbDataType(ANSI(), Sys.time()) dbDataType(ANSI(), Sys.time() - as.POSIXct(Sys.Date())) dbDataType(ANSI(), c("x", "abc")) dbDataType(ANSI(), list(raw(10), raw(20))) dbDataType(ANSI(), I(3)) dbDataType(ANSI(), iris) con <- dbConnect(RSQLite::SQLite(), ":memory:") dbDataType(con, 1:5) dbDataType(con, 1) dbDataType(con, TRUE) dbDataType(con, Sys.Date()) dbDataType(con, Sys.time()) dbDataType(con, Sys.time() - as.POSIXct(Sys.Date())) dbDataType(con, c("x", "abc")) dbDataType(con, list(raw(10), raw(20))) dbDataType(con, I(3)) dbDataType(con, iris) dbDisconnect(con) } \seealso{ Other DBIDriver generics: \code{\link{DBIDriver-class}}, \code{\link{dbConnect}}, \code{\link{dbDriver}}, \code{\link{dbGetInfo}}, \code{\link{dbIsValid}}, \code{\link{dbListConnections}} Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbReadTable}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/DBI-package.Rd0000644000176200001440000000425013060005002013664 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBI-package.R \docType{package} \name{DBI-package} \alias{DBI} \alias{DBI-package} \title{DBI: R Database Interface} \description{ DBI defines an interface 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 (so-called \emph{DBI backends}). } \section{Definition}{ A DBI backend is an R package, which should import the \pkg{DBI} and \pkg{methods} packages. For better or worse, the names of many existing backends start with \sQuote{R}, e.g., \pkg{RSQLite}, \pkg{RMySQL}, \pkg{RSQLServer}; it is up to the backend author to adopt this convention or not. } \section{DBI classes and methods}{ A backend defines three classes, which are subclasses of \linkS4class{DBIDriver}, \linkS4class{DBIConnection}, and \linkS4class{DBIResult}. The backend provides implementation for all methods of these base classes that are defined but not implemented by DBI. All methods have an ellipsis \code{...} in their formals. } \section{Construction of the DBIDriver object}{ The backend must support creation of an instance of its \linkS4class{DBIDriver} subclass with a \dfn{constructor function}. By default, its name is the package name without the leading \sQuote{R} (if it exists), e.g., \code{SQLite} for the \pkg{RSQLite} package. However, backend authors may choose a different name. The constructor must be exported, and it must be a function that is callable without arguments. DBI recommends to define a constructor with an empty argument list. } \examples{ RSQLite::SQLite() } \seealso{ Important generics: \code{\link[=dbConnect]{dbConnect()}}, \code{\link[=dbGetQuery]{dbGetQuery()}}, \code{\link[=dbReadTable]{dbReadTable()}}, \code{\link[=dbWriteTable]{dbWriteTable()}}, \code{\link[=dbDisconnect]{dbDisconnect()}} Formal specification (currently work in progress and incomplete): \code{vignette("spec", package = "DBI")} } \author{ \strong{Maintainer}: Kirill Müller \email{krlmlr+r@mailbox.org} Authors: \itemize{ \item R Special Interest Group on Databases (R-SIG-DB) \item Hadley Wickham } } DBI/man/dbClearResult.Rd0000644000176200001440000000314113055626140014446 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \name{dbClearResult} \alias{dbClearResult} \title{Clear a result set} \usage{ dbClearResult(res, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbClearResult()} returns \code{TRUE}, invisibly, for result sets obtained from both \code{dbSendQuery()} and \code{dbSendStatement()}. An attempt to close an already closed result set issues a warning in both cases. } \description{ Frees all resources (local and remote) associated with a result set. In some cases (e.g., very large result sets) this can be a critical step to avoid exhausting resources (memory, file descriptors, etc.) } \section{Specification}{ \code{dbClearResult()} frees all resources associated with retrieving the result of a query or update operation. The DBI backend can expect a call to \code{dbClearResult()} for each \code{\link[=dbSendQuery]{dbSendQuery()}} or \code{\link[=dbSendStatement]{dbSendStatement()}} call. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") rs <- dbSendQuery(con, "SELECT 1") print(dbFetch(rs)) dbClearResult(rs) dbDisconnect(con) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/dbQuoteIdentifier.Rd0000644000176200001440000000515113055626140015324 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/quote.R \name{dbQuoteIdentifier} \alias{dbQuoteIdentifier} \title{Quote identifiers} \usage{ dbQuoteIdentifier(conn, x, ...) } \arguments{ \item{conn}{A subclass of \linkS4class{DBIConnection}, representing an active connection to an DBMS.} \item{x}{A character vector to quote as identifier.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbQuoteIdentifier()} returns an object that can be coerced to \link{character}, of the same length as the input. For an empty character vector this function returns a length-0 object. An error is raised if the input contains \code{NA}, but not for an empty string. When passing the returned object again to \code{dbQuoteIdentifier()} as \code{x} argument, it is returned unchanged. Passing objects of class \link{SQL} should also return them unchanged. (For backends it may be most convenient to return \link{SQL} objects to achieve this behavior, but this is not required.) } \description{ Call this method to generate a string that is suitable for use in a query as a column name, to make sure that you generate valid SQL and avoid SQL injection. } \section{Specification}{ Calling \code{\link[=dbGetQuery]{dbGetQuery()}} for a query of the format \code{SELECT 1 AS ...} returns a data frame with the identifier, unquoted, as column name. Quoted identifiers can be used as table and column names in SQL queries, in particular in queries like \code{SELECT 1 AS ...} and \code{SELECT * FROM (SELECT 1) ...}. This is also true for column names that are empty strings or contain special characters such as a space, a dot, a comma, or quotes used to mark strings or identifiers, if the database supports this. In any case, checking the validity of the identifier should be performed only when executing a query, and not by \code{dbQuoteIdentifier()}. } \examples{ # Quoting ensures that arbitrary input is safe for use in a query name <- "Robert'); DROP TABLE Students;--" dbQuoteIdentifier(ANSI(), name) # SQL vectors are always passed through as is var_name <- SQL("select") var_name dbQuoteIdentifier(ANSI(), var_name) # This mechanism is used to prevent double escaping dbQuoteIdentifier(ANSI(), dbQuoteIdentifier(ANSI(), name)) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteString}} } DBI/man/dbWithTransaction.Rd0000644000176200001440000000613513055626140015350 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/transactions.R \name{dbWithTransaction} \alias{dbWithTransaction} \alias{dbBreak} \title{Self-contained SQL transactions} \usage{ dbWithTransaction(conn, code, ...) dbBreak() } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{code}{An arbitrary block of R code.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbWithTransaction()} returns the value of the executed code. Failure to initiate the transaction (e.g., if the connection is closed of if \code{\link[=dbBegin]{dbBegin()}} has been called already) gives an error. } \description{ Given that \link{transactions} are implemented, this function allows you to pass in code that is run in a transaction. The default method of \code{dbWithTransaction()} calls \code{\link[=dbBegin]{dbBegin()}} before executing the code, and \code{\link[=dbCommit]{dbCommit()}} after successful completion, or \code{\link[=dbRollback]{dbRollback()}} in case of an error. The advantage is that you don't have to remember to do \code{dbBegin()} and \code{dbCommit()} or \code{dbRollback()} -- that is all taken care of. The special function \code{dbBreak()} allows an early exit with rollback, it can be called only inside \code{dbWithTransaction()}. } \details{ DBI implements \code{dbWithTransaction()}, backends should need to override this generic only if they implement specialized handling. } \section{Specification}{ \code{dbWithTransaction()} initiates a transaction with \code{dbBegin()}, executes the code given in the \code{code} argument, and commits the transaction with \code{\link[=dbCommit]{dbCommit()}}. If the code raises an error, the transaction is instead aborted with \code{\link[=dbRollback]{dbRollback()}}, and the error is propagated. If the code calls \code{dbBreak()}, execution of the code stops and the transaction is silently aborted. All side effects caused by the code (such as the creation of new variables) propagate to the calling environment. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "cash", data.frame(amount = 100)) dbWriteTable(con, "account", data.frame(amount = 2000)) # All operations are carried out as logical unit: dbWithTransaction( con, { withdrawal <- 300 dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal)) dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal)) } ) # The code is executed as if in the curent environment: withdrawal # The changes are committed to the database after successful execution: dbReadTable(con, "cash") dbReadTable(con, "account") # Rolling back with dbBreak(): dbWithTransaction( con, { withdrawal <- 5000 dbExecute(con, "UPDATE cash SET amount = amount + ?", list(withdrawal)) dbExecute(con, "UPDATE account SET amount = amount - ?", list(withdrawal)) if (dbReadTable(con, "account")$amount < 0) { dbBreak() } } ) # These changes were not committed to the database: dbReadTable(con, "cash") dbReadTable(con, "account") dbDisconnect(con) } DBI/man/sqlAppendTable.Rd0000644000176200001440000000343513054310030014603 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/table-insert.R \name{sqlAppendTable} \alias{sqlAppendTable} \alias{sqlAppendTableTemplate} \title{Insert rows into a table} \usage{ sqlAppendTable(con, table, values, row.names = NA, ...) sqlAppendTableTemplate(con, table, values, row.names = NA, prefix = "?", ...) } \arguments{ \item{con}{A database connection.} \item{table}{Name of the table. Escaped with \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}.} \item{values}{A data frame. Factors will be converted to character vectors. Character vectors will be escaped with \code{\link[=dbQuoteString]{dbQuoteString()}}.} \item{row.names}{Either \code{TRUE}, \code{FALSE}, \code{NA} or a string. If \code{TRUE}, always translate row names to a column called "row_names". If \code{FALSE}, never translate row names. If \code{NA}, translate rownames only if they're a character vector. A string is equivalent to \code{TRUE}, but allows you to override the default name. For backward compatibility, \code{NULL} is equivalent to \code{FALSE}.} \item{...}{Other arguments used by individual methods.} \item{prefix}{Parameter prefix to put in front of column id.} } \description{ \code{sqlAppendTable} generates a single SQL string that inserts a data frame into an existing table. \code{sqlAppendTableTemplate} generates a template suitable for use with \code{\link[=dbBind]{dbBind()}}. These methods are mostly useful for backend implementers. } \examples{ sqlAppendTable(ANSI(), "iris", head(iris)) sqlAppendTable(ANSI(), "mtcars", head(mtcars)) sqlAppendTable(ANSI(), "mtcars", head(mtcars), row.names = FALSE) sqlAppendTableTemplate(ANSI(), "iris", iris) sqlAppendTableTemplate(ANSI(), "mtcars", mtcars) sqlAppendTableTemplate(ANSI(), "mtcars", mtcars, row.names = FALSE) } DBI/man/dbGetRowCount.Rd0000644000176200001440000000370713055626140014451 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \name{dbGetRowCount} \alias{dbGetRowCount} \title{The number of rows fetched so far} \usage{ dbGetRowCount(res, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbGetRowCount()} returns a scalar number (integer or numeric), the number of rows fetched so far. After calling \code{\link[=dbSendQuery]{dbSendQuery()}}, the row count is initially zero. After a call to \code{\link[=dbFetch]{dbFetch()}} without limit, the row count matches the total number of rows returned. Fetching a limited number of rows increases the number of rows by the number of rows returned, even if fetching past the end of the result set. For queries with an empty result set, zero is returned even after fetching. For data manipulation statements issued with \code{\link[=dbSendStatement]{dbSendStatement()}}, zero is returned before and after calling \code{dbFetch()}. Attempting to get the row count for a result set cleared with \code{\link[=dbClearResult]{dbClearResult()}} gives an error. } \description{ Returns the total number of rows actually fetched with calls to \code{\link[=dbFetch]{dbFetch()}} for this result set. } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars) rs <- dbSendQuery(con, "SELECT * FROM mtcars") dbGetRowCount(rs) ret1 <- dbFetch(rs, 10) dbGetRowCount(rs) ret2 <- dbFetch(rs) dbGetRowCount(rs) nrow(ret1) + nrow(ret2) dbClearResult(rs) dbDisconnect(con) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/man/dbReadTable.Rd0000644000176200001440000000706313060005002014033 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBConnection.R \name{dbReadTable} \alias{dbReadTable} \title{Copy data frames from database tables} \usage{ dbReadTable(conn, name, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{name}{A character string specifying the unquoted DBMS table name, or the result of a call to \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}.} \item{...}{Other parameters passed on to methods.} } \value{ \code{dbReadTable()} returns a data frame that contains the complete data from the remote table, effectively the result of calling \code{\link[=dbGetQuery]{dbGetQuery()}} with \code{SELECT * FROM }. An error is returned if the table does not exist. An empty table is returned as a data frame with zero rows. The presence of \link{rownames} depends on the \code{row.names} argument, see \code{\link[=sqlColumnToRownames]{sqlColumnToRownames()}} for details: \itemize{ \item If \code{FALSE}, the returned data frame doesn't have row names. \item If \code{TRUE}, a column named "row_names" is converted to row names, an error is raised if no such column exists. \item If \code{NA}, a column named "row_names" is converted to row names if it exists, otherwise no translation occurs. \item If a string, this specifies the name of the column in the remote table that contains the row names, an error is raised if no such column exists. } If the database supports identifiers with special characters, the columns in the returned data frame are converted to valid R identifiers if the \code{check.names} argument is \code{TRUE}, otherwise non-syntactic column names can be returned unquoted. An error is raised if \code{name} cannot be processed with \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}} or if this results in a non-scalar. Unsupported values for \code{row.names} and \code{check.names} (non-scalars, unsupported data types, \code{NA} for \code{check.names}) also raise an error. } \description{ Reads a database table to a data frame, optionally converting a column to row names and converting the column names to valid R identifiers. } \section{Additional arguments}{ The following arguments are not part of the \code{dbReadTable()} generic (to improve compatibility across backends) but are part of the DBI specification: \itemize{ \item \code{row.names} \item \code{check.names} } They must be provided as named arguments. See the "Value" section for details on their usage. } \section{Specification}{ The \code{name} argument is processed as follows, to support databases that allow non-syntactic names for their objects: \itemize{ \item If an unquoted table name as string: \code{dbReadTable()} will do the quoting, perhaps by calling \code{dbQuoteIdentifier(conn, x = name)} \item If the result of a call to \code{\link[=dbQuoteIdentifier]{dbQuoteIdentifier()}}: no more quoting is done } } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "mtcars", mtcars[1:10, ]) dbReadTable(con, "mtcars") dbDisconnect(con) } \seealso{ Other DBIConnection generics: \code{\link{DBIConnection-class}}, \code{\link{dbDataType}}, \code{\link{dbDisconnect}}, \code{\link{dbExecute}}, \code{\link{dbExistsTable}}, \code{\link{dbGetException}}, \code{\link{dbGetInfo}}, \code{\link{dbGetQuery}}, \code{\link{dbIsValid}}, \code{\link{dbListFields}}, \code{\link{dbListResults}}, \code{\link{dbListTables}}, \code{\link{dbRemoveTable}}, \code{\link{dbSendQuery}}, \code{\link{dbSendStatement}}, \code{\link{dbWriteTable}} } DBI/man/dbQuoteString.Rd0000644000176200001440000000514113070016377014511 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/quote.R \name{dbQuoteString} \alias{dbQuoteString} \title{Quote literal strings} \usage{ dbQuoteString(conn, x, ...) } \arguments{ \item{conn}{A subclass of \linkS4class{DBIConnection}, representing an active connection to an DBMS.} \item{x}{A character vector to quote as string.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbQuoteString()} returns an object that can be coerced to \link{character}, of the same length as the input. For an empty character vector this function returns a length-0 object. When passing the returned object again to \code{dbQuoteString()} as \code{x} argument, it is returned unchanged. Passing objects of class \link{SQL} should also return them unchanged. (For backends it may be most convenient to return \link{SQL} objects to achieve this behavior, but this is not required.) } \description{ Call this method to generate a string that is suitable for use in a query as a string literal, to make sure that you generate valid SQL and avoid SQL injection. } \section{Specification}{ The returned expression can be used in a \code{SELECT ...} query, and for any scalar character \code{x} the value of \code{dbGetQuery(paste0("SELECT ", dbQuoteString(x)))[[1]]} must be identical to \code{x}, even if \code{x} contains spaces, quotes (single or double), backticks, or newlines (in any combination) or is itself the result of a \code{dbQuoteString()} call coerced back to character (even repeatedly). If \code{x} is \code{NA}, the result must merely satisfy \code{\link[=is.na]{is.na()}}. The strings \code{"NA"} or \code{"NULL"} are not treated specially. \code{NA} should be translated to an unquoted SQL \code{NULL}, so that the query \code{SELECT * FROM (SELECT 1) a WHERE ... IS NULL} returns one row. } \examples{ # Quoting ensures that arbitrary input is safe for use in a query name <- "Robert'); DROP TABLE Students;--" dbQuoteString(ANSI(), name) # NAs become NULL dbQuoteString(ANSI(), c("x", NA)) # SQL vectors are always passed through as is var_name <- SQL("select") var_name dbQuoteString(ANSI(), var_name) # This mechanism is used to prevent double escaping dbQuoteString(ANSI(), dbQuoteString(ANSI(), name)) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbBind}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}} } DBI/man/dbCallProc.Rd0000644000176200001440000000063613055626140013726 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/deprecated.R \name{dbCallProc} \alias{dbCallProc} \title{Call an SQL stored procedure} \usage{ dbCallProc(conn, ...) } \arguments{ \item{conn}{A \linkS4class{DBIConnection} object, as returned by \code{\link[=dbConnect]{dbConnect()}}.} \item{...}{Other parameters passed on to methods.} } \description{ DEPRECATED } \keyword{internal} DBI/man/dbSetDataMappings.Rd0000644000176200001440000000164213055626140015251 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/deprecated.R \name{dbSetDataMappings} \alias{dbSetDataMappings} \title{Set data mappings between an DBMS and R.} \usage{ dbSetDataMappings(res, flds, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}.} \item{flds}{a field description object as returned by \code{dbColumnInfo}.} \item{...}{Other arguments passed on to methods.} } \description{ This generic is deprecated since no working implementation was ever produced. } \details{ Sets one or more conversion functions to handle the translation of DBMS data types to R objects. This is only needed for non-primitive data, since all DBI drivers handle the common base types (integers, numeric, strings, etc.) The details on conversion functions (e.g., arguments, whether they can invoke initializers and/or destructors) have not been specified. } \keyword{internal} DBI/man/dbBind.Rd0000644000176200001440000001441013057746011013100 0ustar liggesusers% Generated by roxygen2: do not edit by hand % Please edit documentation in R/DBResult.R \name{dbBind} \alias{dbBind} \title{Bind values to a parameterized/prepared statement} \usage{ dbBind(res, params, ...) } \arguments{ \item{res}{An object inheriting from \linkS4class{DBIResult}.} \item{params}{A list of bindings, named or unnamed.} \item{...}{Other arguments passed on to methods.} } \value{ \code{dbBind()} returns the result set, invisibly, for queries issued by \code{\link[=dbSendQuery]{dbSendQuery()}} and also for data manipulation statements issued by \code{\link[=dbSendStatement]{dbSendStatement()}}. Calling \code{dbBind()} for a query without parameters raises an error. Binding too many or not enough values, or parameters with wrong names or unequal length, also raises an error. Calling \code{dbBind()} on a result set already cleared by \code{\link[=dbClearResult]{dbClearResult()}} also raises an error. } \description{ For parametrized or prepared statements, the \code{\link[=dbSendQuery]{dbSendQuery()}} and \code{\link[=dbSendStatement]{dbSendStatement()}} functions can be called with statements that contain placeholders for values. The \code{dbBind()} function binds these placeholders to actual values, and is intended to be called on the result set before calling \code{\link[=dbFetch]{dbFetch()}} or \code{\link[=dbGetRowsAffected]{dbGetRowsAffected()}}. } \details{ \pkg{DBI} supports parametrized (or prepared) queries and statements via the \code{dbBind()} generic. Parametrized queries are different from normal queries in that they allow an arbitrary number of placeholders, which are later substituted by actual values. Parametrized queries (and statements) serve two purposes: \itemize{ \item The same query can be executed more than once with different values. The DBMS may cache intermediate information for the query, such as the execution plan, and execute it faster. \item Separation of query syntax and parameters protects against SQL injection. } The placeholder format is currently not specified by \pkg{DBI}; in the future, a uniform placeholder syntax may be supported. Consult the backend documentation for the supported formats. For automated testing, backend authors specify the placeholder syntax with the \code{placeholder_pattern} tweak. Known examples are: \itemize{ \item \code{?} (positional matching in order of appearance) in \pkg{RMySQL} and \pkg{RSQLite} \item \code{$1} (positional matching by index) in \pkg{RPostgres} and \pkg{RSQLite} \item \code{:name} and \code{$name} (named matching) in \pkg{RSQLite} } } \section{Specification}{ \pkg{DBI} clients execute parametrized statements as follows: \enumerate{ \item Call \code{\link[=dbSendQuery]{dbSendQuery()}} or \code{\link[=dbSendStatement]{dbSendStatement()}} with a query or statement that contains placeholders, store the returned \linkS4class{DBIResult} object in a variable. Mixing placeholders (in particular, named and unnamed ones) is not recommended. It is good practice to register a call to \code{\link[=dbClearResult]{dbClearResult()}} via \code{\link[=on.exit]{on.exit()}} right after calling \code{dbSendQuery()} or \code{dbSendStatement()} (see the last enumeration item). \item Construct a list with parameters that specify actual values for the placeholders. The list must be named or unnamed, depending on the kind of placeholders used. Named values are matched to named parameters, unnamed values are matched by position in the list of parameters. All elements in this list must have the same lengths and contain values supported by the backend; a \link{data.frame} is internally stored as such a list. The parameter list is passed to a call to \code{dbBind()} on the \code{DBIResult} object. \item Retrieve the data or the number of affected rows from the \code{DBIResult} object. \itemize{ \item For queries issued by \code{dbSendQuery()}, call \code{\link[=dbFetch]{dbFetch()}}. \item For statements issued by \code{dbSendStatements()}, call \code{\link[=dbGetRowsAffected]{dbGetRowsAffected()}}. (Execution begins immediately after the \code{dbBind()} call, the statement is processed entirely before the function returns.) } \item Repeat 2. and 3. as necessary. \item Close the result set via \code{\link[=dbClearResult]{dbClearResult()}}. } The elements of the \code{params} argument do not need to be scalars, vectors of arbitrary length (including length 0) are supported. For queries, calling \code{dbFetch()} binding such parameters returns concatenated results, equivalent to binding and fetching for each set of values and connecting via \code{\link[=rbind]{rbind()}}. For data manipulation statements, \code{dbGetRowsAffected()} returns the total number of rows affected if binding non-scalar parameters. \code{dbBind()} also accepts repeated calls on the same result set for both queries and data manipulation statements, even if no results are fetched between calls to \code{dbBind()}. At least the following data types are accepted: \itemize{ \item \link{integer} \item \link{numeric} \item \link{logical} for Boolean values (some backends may return an integer) \item \link{NA} \item \link{character} \item \link{Date} \item \link{POSIXct} timestamps \item \link{POSIXlt} timestamps \item lists of \link{raw} for blobs (with \code{NULL} entries for SQL NULL values) } } \examples{ con <- dbConnect(RSQLite::SQLite(), ":memory:") dbWriteTable(con, "iris", iris) # Using the same query for different values iris_result <- dbSendQuery(con, "SELECT * FROM iris WHERE [Petal.Width] > ?") dbBind(iris_result, list(2.3)) dbFetch(iris_result) dbBind(iris_result, list(3)) dbFetch(iris_result) dbClearResult(iris_result) # Executing the same statement with different values at once iris_result <- dbSendStatement(con, "DELETE FROM iris WHERE [Species] = $species") dbBind(iris_result, list(species = c("setosa", "versicolor", "unknown"))) dbGetRowsAffected(iris_result) dbClearResult(iris_result) nrow(dbReadTable(con, "iris")) dbDisconnect(con) } \seealso{ Other DBIResult generics: \code{\link{DBIResult-class}}, \code{\link{dbClearResult}}, \code{\link{dbColumnInfo}}, \code{\link{dbFetch}}, \code{\link{dbGetInfo}}, \code{\link{dbGetRowCount}}, \code{\link{dbGetRowsAffected}}, \code{\link{dbGetStatement}}, \code{\link{dbHasCompleted}}, \code{\link{dbIsValid}}, \code{\link{dbQuoteIdentifier}}, \code{\link{dbQuoteString}} } DBI/.Rinstignore0000644000176200001440000000002512511422440013144 0ustar liggesusersinst/doc/figure1.pdf