A bit of cleanup (#190)

CONTRIBUTING.md

@@ -1,7 +1,7 @@
-# Contributing to {dittodb}
+# Contributing to `dittodb`
 
-This outlines how to propose a change to {dittodb}. For detailed information 
-about developing {dittodb} see the [developing {dittodb} vignette](articles/developing-dittodb.html).
+This outlines how to propose a change to `dittodb`. For detailed information 
+about developing `dittodb` see the [developing `dittodb` vignette](articles/developing-dittodb.html).
 
 
 ### Fixing typos
@@ -36,5 +36,5 @@ your PR.
 
 ### Code of Conduct
 
-Please note that the {dittodb} project is released with a  [Contributor Code of Conduct](CODE_OF_CONDUCT.md). 
+Please note that the `dittodb` project is released with a  [Contributor Code of Conduct](CODE_OF_CONDUCT.md). 
 By contributing to this project, you agree to abide by its terms.

DESCRIPTION

@@ -1,6 +1,6 @@
 Package: dittodb
 Title: A Test Environment for Database Requests
-Version: 0.1.7.9000
+Version: 0.1.8
 Authors@R: c(
     person(given = "Jonathan",
            family = "Keane",

NEWS.md

@@ -1,5 +1,5 @@
-# dittodb (development version)
-* Improved error messages for connections made before running `start_db_capture()`. (#183)
+# dittodb 0.1.8
+* Improved error messages for connections made before running `start_db_capture()`. (@KoderKow, #183)
 * Added to the `dbplyr` unique table names that are ignored to work with the newest `dbplyr` table names. (#188)
 
 # dittodb 0.1.7

R/capture-requests.R

@@ -435,14 +435,15 @@ get_redactor <- function() {
   return(NULL)
 }
 
-#' Check dittodb environment path
+#' Check for dittodb environment path
 #'
 #' This function should generally not be used, but must be exported for the
 #' query recording function to work properly
 #'
 #' @param .dittodb_env Environment object
 #'
 #' @return `NULL`, invisibly.
+#' @keywords internal
 #' @export
 check_db_path <- function(.dittodb_env) {
   if (is.null(.dittodb_env$db_path)) {

R/connection.R

@@ -4,7 +4,7 @@
 #' [DBI](https://CRAN.R-project.org/package=DBI) methods of the same name.
 #' Instead of actually interacting with a database, they read in mock responses
 #' and the code proceeds after that. These aren't used directly, but are part of
-#' how {dittodb} works.
+#' how `dittodb` works.
 #'
 #' @param conn a database connection (for dispatch with these methods, it should
 #'   be of class `DBIMockConnection`)

R/mock-db.R

@@ -4,7 +4,7 @@
 #' use fixtures instead of connecting to a real database. Alternatively, you can
 #' start and stop using a mocked database with `start_mock_db()` and
 #' `stop_mock_db()` respectively.to execute the whole thing without needing to
-#' remember to stop the mocking. When testing with {dittodb}, it will look for
+#' remember to stop the mocking. When testing with `dittodb`, it will look for
 #' fixtures in all entries of [`db_mock_paths`].
 #'
 #' You only need to use one approach: either use `start_mock_db()` to start
@@ -17,7 +17,7 @@
 #'
 #' Connections should be made after `start_mock_db()` if you're using that
 #' function or they should be made inside of `with_mock_db()` if you're using
-#' that function because {dittodb} uses the database name (given in `dbname` or
+#' that function because `dittodb` uses the database name (given in `dbname` or
 #' `Database` argument of [`dbConnect`] depending on the driver) to separate
 #' different fixtures. For ODBC connections with only a dsn provided, the dsn is
 #' used for this directory.

R/mock-paths.R

@@ -111,7 +111,7 @@ set_default_db_mock_paths <- function() {
 #' Run the DBI queries in an alternate mock directory
 #'
 #' When testing with dittodb, wrap your tests in `with_mock_path({})` to use the
-#' database fixtures located in other directories. {dittodb} will look for
+#' database fixtures located in other directories. `dittodb` will look for
 #' fixtures in the directory specified by the user, which can be a temporary
 #' or permanent location.
 #'

R/nycflights13-sql.R

@@ -154,11 +154,11 @@ nycflights13_create_sqlite <- function(location = ":memory:", ...) {
 
 #' An SQLite connection to a subset of nycflights13
 #'
-#' Included with {dittodb} is a small subset of
+#' Included with `dittodb` is a small subset of
 #' [`nycflights13`](https://CRAN.R-project.org/package=nycflights13)
 #' prepopulated into a `sqlite` database.
 #'
-#' This database is helpful for getting to know {dittodb} and running example
+#' This database is helpful for getting to know `dittodb` and running example
 #' code. It contains a small subset of the data in nycflights13: namely only the
 #' flights and planes that had a destination of ORD or MDW (the codes for the
 #' two major airports in Chicago) in February of 2013. The airports table has

R/redact.R

@@ -1,7 +1,7 @@
 #' Redact columns from a dataframe with the default redactors
 #'
 #' This function redacts the columns specified in `columns` in the data given in
-#' `data` using {dittodb}'s standard redactors.
+#' `data` using `dittodb`'s standard redactors.
 #'
 #' The column names given in the `columns` argument are treated as regular
 #' expressions, however they always have `^` and `$` added to the beginning and

R/use-dittodb.R

@@ -1,18 +1,18 @@
-#' Use {dittodb} in your tests
+#' Use `dittodb` in your tests
 #'
-#' If you would like to use {dittodb} in your package, and you are already using
+#' If you would like to use `dittodb` in your package, and you are already using
 #' [{testthat}](https://CRAN.R-project.org/package=testthat), use this function to
-#' add {dittodb} to Suggests in the package DESCRIPTION and loads it in
+#' add `dittodb` to Suggests in the package DESCRIPTION and loads it in
 #' `tests/testthat/helper.R`. Call it once when you're setting up a new package
 #' test suite.
 #'
 #' This function should be called with the path to your package source as the
-#' `path` argument. The function is idempotent: if {dittodb} is already added to
+#' `path` argument. The function is idempotent: if `dittodb` is already added to
 #' these files, no additional changes will be made.
 #'
 #' It will:
 #'
-#' * add {dittodb} to the `Suggests` field of the DESCRIPTION file in the
+#' * add `dittodb` to the `Suggests` field of the DESCRIPTION file in the
 #' current working directory
 #' * add `library(dittodb)` to the file `tests/testthat/helper.R` (creating it
 #' if it doesn't already exist)

R/utils.R

@@ -134,18 +134,18 @@ ignore_quotes <- function(statement) {
   return(statement)
 }
 
-#' Set {dittodb}'s debug level
+#' Set `dittodb`'s debug level
 #'
-#' It can be helpful to see what's going on by increasing {dittodb}'s verbosity
+#' It can be helpful to see what's going on by increasing `dittodb`'s verbosity
 #' which will show what's going on under the hood (e.g. what queries are being
 #' requested, from where). This sets the option `dittodb.debug` to the value
 #' given in the `level` argument. The option can be set directly with
 #' `options(dittodb.debug = n)` as well.
 #'
 #' The `level` argument is a numeric, where 0 is the default and (relatively)
-#' silent. The higher the level, the more verbose {dittodb} will be.
+#' silent. The higher the level, the more verbose `dittodb` will be.
 #'
-#' Currently, {dittodb} only has one level of debugging (any value 1 or
+#' Currently, `dittodb` only has one level of debugging (any value 1 or
 #' greater), but more might be used in the future.
 #'
 #' @param level a numeric, the level to set to (e.g. 1)
@@ -194,7 +194,7 @@ get_type <- function(statement) {
 #' Sanitize Table id
 #'
 #' Tables are identified and specified with a large number of ways across
-#' drivers. For the purposes of {dittodb}, the details are less important since
+#' drivers. For the purposes of `dittodb`, the details are less important since
 #' we almost always just want a flat representation (_ie_ for filenames). This
 #' takes the various formats and returns a string with various elements
 #' separated by dots.

README.md

@@ -8,9 +8,9 @@
 [![Lifecycle: stable](https://lifecycle.r-lib.org/articles/figures/lifecycle-stable.svg)](https://lifecycle.r-lib.org/articles/stages.html)
 <!-- badges: end -->
 
-{dittodb} is a package that makes testing against databases easy. When writing code that relies on interactions with databases, testing has been difficult without recreating test databases in your continuous integration (aka CI) environment, or resorting to using SQLite databases instead of the database engines you have in production. Both have their downsides: recreating database infrastructure is slow, error prone, and hard to iterate with. Using SQLite works well, right up until you use a feature (like [a full outer join](https://www.sqlite.org/omitted.html)) or has [quirks](https://www.sqlite.org/quirks.html) that might differ from your production database. {dittodb} solves this by recording database interactions, saving them as mocks, and then replaying them seamlessly during testing. This means that if you can get a query from your database, you can record the response and reliably reproduce that response in tests.
+`dittodb` is a package that makes testing against databases easy. When writing code that relies on interactions with databases, testing has been difficult without recreating test databases in your continuous integration (aka CI) environment, or resorting to using SQLite databases instead of the database engines you have in production. Both have their downsides: recreating database infrastructure is slow, error prone, and hard to iterate with. Using SQLite works well, right up until you use a feature (like [a full outer join](https://www.sqlite.org/omitted.html)) or has [quirks](https://www.sqlite.org/quirks.html) that might differ from your production database. `dittodb` solves this by recording database interactions, saving them as mocks, and then replaying them seamlessly during testing. This means that if you can get a query from your database, you can record the response and reliably reproduce that response in tests.
 
-{dittodb} is heavily inspired by [{httptest}](https://CRAN.R-project.org/package=httptest), if you've used {httptest} before, you'll find many of the interactions similar.
+`dittodb` is heavily inspired by [{httptest}](https://CRAN.R-project.org/package=httptest), if you've used {httptest} before, you'll find many of the interactions similar.
 
 ## A quick example
 Say we have a database with some [{nycflights}](https://CRAN.R-project.org/package=nycflights13) data in it and we are writing functions that query this data that we want to test. 
@@ -130,26 +130,26 @@ with_mock_db({
 All without having to ever set a database up on Travis or GitHub Actions 🎉
 
 ## Installation
-Currently, {dittodb} is on CRAN (The Comprehensive R Archive Network), so you can install it with `install.packages("dittodb")`. 
+Currently, `dittodb` is on CRAN (The Comprehensive R Archive Network), so you can install it with `install.packages("dittodb")`. 
 
 ### Installing a development version
 
 If you would like to use the development version, you can install from GitHub with: `remotes::install_github("ropensci/dittodb")`
 
 _Note_ You may need to add `@main` at the end if you are using a version of {remotes} prior to 2.2.0. Alternatively, you can use `remotes::install_git()` directly: `remotes::install_git("https://github.com/ropensci/dittodb.git")`
 
-## Setup a package to use {dittodb}
-Use the function `dittodb::use_dittodb()` to easily get started using {dittodb}. It will add {dittodb} to `Suggests` in the `DESCRIPTION` file and add `library(dittodb)` to `tests/testthat/helper.R`.
+## Setup a package to use `dittodb`
+Use the function `dittodb::use_dittodb()` to easily get started using `dittodb`. It will add `dittodb` to `Suggests` in the `DESCRIPTION` file and add `library(dittodb)` to `tests/testthat/helper.R`.
 
 ## Development
-There is extensive information about developing {dittodb} in the vignette [Developing {dittodb}](https://dittodb.jonkeane.com/articles/developing-dittodb.html), please read that before trying to make changes to {dittodb} or running any of the scripts provided in the `db-setup` directory.
+There is extensive information about developing `dittodb` in the vignette [Developing `dittodb`](https://dittodb.jonkeane.com/articles/developing-dittodb.html), please read that before trying to make changes to `dittodb` or running any of the scripts provided in the `db-setup` directory.
 
-In order to test {dittodb} recording functionality locally or on continuous integration, it is helpful to have databases with test data available. This can be accomplished using the scripts in the `db-setup` directory. By default, {dittodb} does not run any tests that require database infrastructure locally.
+In order to test `dittodb` recording functionality locally or on continuous integration, it is helpful to have databases with test data available. This can be accomplished using the scripts in the `db-setup` directory. By default, `dittodb` does not run any tests that require database infrastructure locally.
 
-To get local databases, the easiest way is to use docker and run either the `db-setup/local-mariadb-docker-setup.sh` or `db-setup/local-postgres-docker-setup.sh` which will pull a docker image and set up a test database with the user and passwords that the {dittodb} tests are expecting (and will stop and remove the docker images if they are present). 
+To get local databases, the easiest way is to use docker and run either the `db-setup/local-mariadb-docker-setup.sh` or `db-setup/local-postgres-docker-setup.sh` which will pull a docker image and set up a test database with the user and passwords that the `dittodb` tests are expecting (and will stop and remove the docker images if they are present). 
 
 On continuous integration, (using GitHub Actions) these scripts in the `db-setup` directory are used to set up these test databases so we can run integration tests (predominantly in the file `tests/testthat/test-dbi-generic-integration.R`).
 
 ## Code of Conduct
 
-Please note that the {dittodb} project is released with a [Contributor Code of Conduct](https://dittodb.jonkeane.com/CODE_OF_CONDUCT). By contributing to this project, you agree to abide by its terms.
+Please note that the `dittodb` project is released with a [Contributor Code of Conduct](https://dittodb.jonkeane.com/CODE_OF_CONDUCT). By contributing to this project, you agree to abide by its terms.

cran-comments.md

@@ -1,5 +1,5 @@
 ## Test environments
-* local R installation MacOS 12.6.8, R 4.3.0
+* local R installation MacOS 14.4.1, R 4.3.3
 * ubuntu 22.04 (on GitHub actions), R 3.6-4.3, devel
 * macOS (on GitHub actions), R 4.2, 4.3
 * windows (on GitHub actions), R 4.3