WIP: Support new dbplyr.trace option

[krlmlr]

Print SQL before querying or executing, and a corresponding message when done.

Closes #827.

[mgirlich]

@krlmlr Do you want to continue with this? 😄

[krlmlr]

What do you want this to look like?

[mgirlich]

I'm basically quite happy with the approach already. As this was your idea: is there anything else you want/need?

What's missing from this PR in my opinion is:

• NEWS
• It might make sense to add a better visual indicator between queries. In the following example it is a bit too difficult to quickly distinguish the two queries:

[17]: dbExecute()
ANALYZE `dbplyr_011`
[17]: dbExecute() done
[18]: dbExecute()
INSERT INTO `dbplyr_010` (`x`, `y`)
SELECT *
FROM (
  SELECT *
  FROM `dbplyr_011`
) AS `...y`
WHERE NOT EXISTS (
  SELECT 1 FROM `dbplyr_010`
  WHERE (`dbplyr_010`.`x` = `...y`.`x`)
)
[18]: dbExecute() done

[hadley]

Closing, since if you're still interested, you'd now want to implement on top of db_execute()/db_get_query().

[krlmlr]

I'm confused. Are db_execute() and db_get_query() becoming generics? They don't seem to be in 267a12e .

[hadley]

Why would they need to be generics?

[krlmlr]

If they are not, then this may mean that you're asking me to reimplement this PR using new idioms. I'd be happy to review a PR instead.

[hadley]

I'm not sure this feature is necessary any more, now that errors will include the generated SQL.