backend_db: Database generics.
In sctyner/dplyr050: A Grammar of Data Manipulation

Description Usage Arguments Details Value

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

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, ...)

`con`	A database connection.
`table`	A string, the table name.
`fields`	A list of fields, as in a data frame.

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.

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.

sctyner/dplyr050 documentation built on May 17, 2019, 2:22 p.m.