RE: https://fosstodon.org/@R_devs_news/115966889498732323

now that is very sensible

2. #' @importFrom duckplyr select filter mutate arrange count summarize

to take these functions and expect that duckplyr will figure out how to fall back onto dplyr when needed.

4/4

P.S. @kirill hope you can shed some light

Shouting to the void: How to properly namespace #duckdb / #duckplyr in my #rstats packages?

One of @hadleywickham core style recommendations for package development is that every external function needs to be explicitly namespaced:

function_in_my_package <- function(df, x, ...) {
df |> dplyr::mutate(xx = stringr::str_do_something(x))
# implict return
}

1/maybe 4

Going through some #duckdb learning through https://duckplyr.tidyverse.org/articles/large.html

1. Get a DuckDB SQL server in memory:

path_duckdb <- tempfile(fileext = ".duckdb")
con <- DBI::dbConnect(duckdb::duckdb(path_duckdb))
DBI::dbWriteTable(con, "mtcars", mtcars)

2. Try explain(), compute(), collect() (the dplyr words dispatched by dbplyr), compute_parquet() without bringing the data to memory (the result may be larger than memory)

Going after #arrow #parquet #rstats #DBI beehive:

is there a mostly lazy way to make a local parquet copy of a remote SQL table? I want to avoid collect() but may be it is unavoidable. I could not find a reasonable example in the Cookbook. arrow::write_dataset() does not want to take tbl_Microsoft_SQL_Server as an input.