Accept unnamed dm objects in dm() and dm_mutate_tbl()

[krlmlr]

similarly to how unnamed tibbles are accepted in tibble() and mutate() :

library(dm)

dm(dm_nycflights13())
#> Error in `abort_dm_invalid()` at dm/R/validate.R:29:4:
#> ! This `dm` is invalid, reason: Not all entries in `def$data` are of class `data.frame` or `tbl_dbi`. Check `dm_get_tables()`.

^{Created on 2022-06-06 by the reprex package (v2.0.1)}

[moodymudskipper]

Unnamed arguments in dm already work

dm <- dm(iris)
dm
#> ── Metadata ────────────────────────────────────────────────────────────────────
#> Tables: `iris`
#> Columns: 5
#> Primary keys: 0
#> Foreign keys: 0

This doesn't however :

dm_mutate_tbl(dm, cars)
#> Error in dm_mutate_tbl(dm, cars): is_named(new_tables) is not TRUE

This doesn't either, though not tremendously useful :

dm <- dm(a = iris)
dm_mutate_tbl(dm, a)
#> Error in list2(...): object 'a' not found

This neither :

dm <- dm(a = iris)
dm_mutate_tbl(dm, b = head(a))
#> Error in list2(...): object 'a' not found

Should the 2 latter cases be supported ? I know I've already needed the last one.

[moodymudskipper]

See also : https://github.com/cynkra/dm/issues/859

I also feel that dm_add_tbl(dm, b = head(a)) should work. But I'd like to understand why we need dm_add_tbl() at all rather than generalising dm_mutate_tbl() so it behaves more like {dplyr} : create or modify.

If we had this we could also have dm_transmute_tbl() to easily fetch some tables from a big dm and sample them on the go.

[krlmlr]

@moodymudskipper: Can you please revisit your comments in the light of the new reprex in the OP, and add new issues as necessary?

[krlmlr]

Not sure about dm_mutate_tbl(), but for dm(), as of 1.0.0:

options(conflicts.policy = list(warn = FALSE))
library(dm)

dm(dm(x = tibble(a = 1)))
#> ── Metadata ────────────────────────────────────────────────────────────────────
#> Tables: `x`
#> Columns: 1
#> Primary keys: 0
#> Foreign keys: 0

^{Created on 2023-08-20 with reprex v2.0.2}