dplyr (version 0.5.0)

backend_db: Database generics.

Description

These generics execute actions on the database. Most generics have a method for DBIConnection which typically just call the standard DBI S4 method.

Usage

db_list_tables(con)
db_has_table(con, table)
db_data_type(con, fields)
db_save_query(con, sql, name, temporary = TRUE, ...)
db_begin(con, ...)
db_commit(con, ...)
db_rollback(con, ...)
db_create_table(con, table, types, temporary = FALSE, ...)
db_insert_into(con, table, values, ...)
db_create_indexes(con, table, indexes = NULL, unique = FALSE, ...)
db_create_index(con, table, columns, name = NULL, unique = FALSE, ...)
db_drop_table(con, table, force = FALSE, ...)
db_analyze(con, table, ...)
db_explain(con, sql, ...)
db_query_fields(con, sql, ...)
db_query_rows(con, sql, ...)

Arguments

con

A database connection.

table

A string, the table name.

fields

A list of fields, as in a data frame.

Value

Usually a logical value indicating success. Most failures should generate an error. However, db_has_table() should return NA if temporary tables cannot be listed with dbListTables (due to backend API limitations for example). As a result, you methods will rely on the backend to throw an error if a table exists when it shouldn't.

Details

Note, a few backend methods do not call the standard DBI S4 methods including

• db_data_type: Calls DBI's dbDataType for every field (e.g. data frame column) and returns a vector of corresponding SQL data types

• db_save_query: Builds and executes CREATE [TEMPORARY] TABLE <table> ... SQL command.

• db_create_table: Builds and executes CREATE [TEMPORARY] TABLE <table> ... SQL command.

• db_create_index: Builds and executes CREATE INDEX <name> ON <table> SQL command.

• db_drop_table: Builds and executes DROP TABLE [IF EXISTS] <table> SQL command.

• db_analyze: Builds and executes ANALYZE <table> SQL command.

• db_insert_into and db_explain: do not have methods calling corresponding DBI methods. The latter because no underlying DBI S4 method exists and the former because calls to the corresponding DBI S4 method (dbWriteTable) need to be able to specify an appropriate combination of values for non-standard append and overwrite arguments.

Currently, copy_to is the only user of db_begin(), db_commit(), db_rollback(), db_create_table(), db_insert_into(), db_create_indexes(), db_drop_table() and db_analyze(). If you find yourself overriding many of these functions it may suggest that you should just override copy_to instead.