Execute DuckLake operations from dplyr queries
Arguments
- .data
A dplyr query object (tbl_lazy) with accumulated operations
- table_name
The target table name for the operation. If not provided, will be extracted from the table attribute (set by get_ducklake_table())
- .quiet
Logical, whether to suppress the SQL trace (default TRUE). With
.quiet = FALSEthe original dplyr SQL, the translated statement, and the number of rows affected are emitted as messages.
Details
This function automatically detects the type of operation based on dplyr verbs:
Filter-only queries on
table_namegenerate DELETE operations (removes rows that DON'T match filter)Queries with mutate() on
table_namegenerate UPDATE operationsReads from other tables generate INSERT operations, appending their result into
table_namewith columns matched by name;filter()and joins are fine here, since the whole query just feeds the INSERT
A plain read from table_name itself is refused, since inserting a
table's own rows back into it would duplicate them. Pipelines that
compile to a subquery over table_name (grouped filters, mutate()
followed by filter()) are also refused rather than mistranslated. Use
show_ducklake_query() to preview the generated SQL without running it.
Examples
lake_dir <- tempfile("exec_lake_")
dir.create(lake_dir)
attach_ducklake("exec_lake", lake_path = lake_dir)
create_table(data.frame(id = 1:3, status = "pending"), "jobs")
# Update specific rows (table name inferred)
get_ducklake_table("jobs") |>
dplyr::filter(id == 1) |>
dplyr::mutate(status = "updated") |>
ducklake_exec()
#> [1] 1
# Delete rows matching a filter
get_ducklake_table("jobs") |>
dplyr::filter(status == "pending") |>
ducklake_exec()
#> [1] 1
# Or provide the table name explicitly
get_ducklake_table("jobs") |>
dplyr::mutate(status = "done") |>
ducklake_exec("jobs")
#> [1] 2
detach_ducklake("exec_lake", shutdown = TRUE)
unlink(lake_dir, recursive = TRUE)
