Handle con object differently #2

Activity

1. hadley commented on Oct 25, 2017

   

   hadley

   on Oct 25, 2017

   More actions

   If the purpose of sqlr is SQL generation, and you imagine it being primarily used via other packages (e.g. dplyr or DBI), I think it would be better to rip this out altogether and require the user to always provide a connection.
2. nbenn commented on Oct 25, 2017

   

   nbenn

   on Oct 25, 2017

   OwnerAuthor

   More actions

   The reason for what I did is that currently the definition of a table is for example:

   tbl_spec(name = "name",
            cols = col_spec(name = "id",
                            type = col_int(unsigned = TRUE),
                            nullable = FALSE,
                            auto_increment = TRUE),
            engine = "InnoDB")

   At every level I need the con object. In order not to manually pass it along, one thing I have been looking into is: e.g. in col_spec() to capture type with rlang::enquo and using con passed to col_spec to rlang::lang_modify the call to col_int (cf. here)

   Do you think such an approach makes more sense?

   I will have a closer look at dbplyr. Maybe I can come up with something less clumsy. Thanks for your inputs.
3. nbenn commented on Sep 24, 2026

   

   nbenn

   on Sep 24, 2026

   OwnerAuthor

   More actions

   Resolved by #7: the constructors no longer take a connection, sqlr_render() takes an explicit dialect, and sqlr_reflect() requires con. No default connection is stored anywhere.
4. nbenn

   closed this as completedon Sep 24, 2026