Handle con object differently

[nbenn]

I also don't like the way that the default connection is defined/established, but I think that's fairly easy to fix (although it does have broader implications for the API) DBI/issues#74

@hadley I guess you don't like how I save the con object to the sqlr:::config env and subsequently get it from there (@krlmlr also didn't like this). Do you have any suggestions? Do you think it would make sense to wrap the query in an R6 class (inspired by dbplyr)?

[hadley]

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.

[nbenn]

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.