To make getting started with rquery (an advanced query generator for R) easier we have re-worked the package README for various data-sources (including SparkR!).
Here are our current examples:
rqueryandMonetDBLiterqueryandRPostgreSQLrqueryandRPostgresrqueryandRSQLiterqueryandSparkRrqueryandsparklyr
For the MonetDBLite the query diagrammer shows a repeated calculation that we decided was best to leave in.

And the RSQLite diagram shows the consequences of replacing window functions with joins.

jmount
Data Scientist and trainer at Win Vector LLC. One of the authors of Practical Data Science with R.
RPostgreSQL has been updated last time almost two years ago. Any particular reason not to use RPostgres?
I guess I’ll have to start this answer with the weak apology: “well you asked.” (Actually this is both “asked a lot verbally” and in the “nobody says that” categories. So, apologies taking the chance to discuss this in writing here.)
About
RPostgreSQLversusRPostgres.When I last tested with
RPostgresit was a very bad experience including returningint64for row counts (not a baseRtype, but a class from thebit64package; broke a lot of code), didn’t work withRedshift(a service I was using a lot at the time), and had a lot of other issues. I’ve patched around what I could, and probably will look into adding aRPostgresexample. But for production work I tryRPostgreSQLfirst.And frankly given the contributors I worry
RPostgreswill be abandoned for a proprietaryRStudio Professional Driver, or that the driver will become “tidyverseonly” and return non base-Rdata types (breaking other code, forcing those packages on all, and making it more difficult to interoperate with other extension packages such asdata.table).Also I found
RPostgreSQLto be excellent. It had a couple of variations fromDBI, butrqueryhas an adapter layer to work through such things.Finally I am not sure if you are serious with the “updated last time almost two years ago” point.
RPostgresitself was last updated over 6 months ago, and only has just over a year of public experience and tuning, compared toRPostgreSQLhaving just over 10 years of public experience and tuning. One could ask a similar question: “why usemagrittr, given it hasn’t had an update in over 4 years?” (there are other options, including our ownwrapr).When I said that RPostgreSQL hasn’t been updated in almost two years, I meant latest CRAN release which is dated 2017-06-24. However, I concede, I’ve been a bit unfair since I was comparing latest GitHub activity of RPostgres with CRAN release date of RPostgreSQL. Those are not the same, obviously. But I think we both would agree that RPostgres is a bit more maintained.
I have to say, I was expecting your response to be pretty much what you wrote and I wouldn’t have asked if I didn’t see sparklyr in the list of backends rquery supports.
Thanks for both your comments and your patience. You have some good points. I’ve got the
RPostgresexample up now (it is just a driver swap, as I had already patched around its issues).I actually see the difference between
sparklyrandSparkRas a bit wider (and favoringsparklyr, gettingSparkRto work was not a simple matter of changing drivers- but required much more at the adapter layer).Do you have much experience (first- or second-hand) of using
rquerywith SQL Server? I tried it as I wanted to test outrqdatatableat work, but got errors when trying the setup stages of therqueryintroduction. I notice that SQL Server isn’t on that list: is rquery not compatible with it? Sorry if this isn’t the right place to ask.SQL Server isn’t tested/supported as we don’t have a copy to test or develop against. Messages during the connection tests are normal, as that is where the package test the edges of the database.
rqdatatableis thedata.tablerealization ofrquery, so it does not use a database connection.