Discussion

ggsql: A grammar of graphics for SQL

thomasp85: The new visualisation tool from Posit. Combines SQL with the grammar of graphics, known from ggplot2, D3, and plotnine

mi_lk: I don't think D3 uses grammar of graphics model?

thomasp85: I'd say it does, though it is certainly much more low-level than e.g. ggplot2. But the basic premises of the building blocks described be Leland Wilkinson is there

thomasp85: I'm one of the authors - happy to take any questions!

anentropic: Maybe I skim read it too fast, but I did not find any clear description in the blog post or website docs of how this relates to SQL databasesI was kind of guessing that it doesn't run in a database, that it's a SQL-like syntax for a visualisation DSL handled by front end chart library.That appears to be what is described in https://ggsql.org/get_started/anatomy.htmlBut then https://ggsql.org/faq.html has a section, "Can I use SQL queries inside the VISUALISE clause," which says, "Some parts of the syntax are passed on directly to the database".The homepage says "ggsql interfaces directly with your database"But it's not shown how that happens AFAICTconfused

password4321: Yes this was my question as well, an example showing all the plumbing/dependencies to generate a graph from an external database server would be very helpful.

thomasp85: We certainly plan to create a few videos showing how to set it up and use it. If you use it in Positron with the ggsql extension it can interact directly with the connection pane to connect to the various backends you have there

thomasp85: That is fair - it is somewhat of a special concept.ggsql connects directly with your database backend (if you wish - you can also run it with an in-memory DuckDB backend). Your visual query is translated into a SQL query for each layer of the visualisation and the resulting table is then used for rendering.E.g.VISUALISE page_views AS x FROM visits DRAW smoothwill create a SQL query that calculates a smoothing kernel over the data and returns points along that. Those points are then used to create the final line chart

efromvt: Love the layering approach - that solves a problem I’ve had with other sql/visual hybrids as you move past the basics charts.

getnormality: I skimmed the article for an explanation of why this is needed and didn't find one I could follow.Is the point that we want to be able to ask for visualizations directly against tables in remote SQL databases, instead of having to pull the data into R data frames first so we can run ggplot on it?But why create a new SQL-like language? Wouldn't it be more direct to extend ggplot to support dbplyr tbl objects, and have ggplot generate the SQL?Is this new language some sort of middleware that is intended to support that?

gh5000: It is conceivable that this could become a duckdb extension, such that it can be used from within the duckdb CLI? That would be pretty slick.

dartharva: Would be awesome if somehow coupled into Evidence.dev

kasperset: Will this ever integrate rest of the ggplot2 dependent packages described here: https://exts.ggplot2.tidyverse.org/gallery/ in the near or distant future? Sorry if it already mentioned somewhere.

thomasp85: I don't think we will get the various niche geoms that have been developed by the ggplot2 community anytime soon.The point of this is not to superseed ggplot2 in any way, but to provide a different approach which can do a lot of the things ggplot2 can, and some that it can't. But ggplot2 will remain more powerful for a lot of tasks in many years to come I predict

thomasp85: That is conceivable, not a top priority as we want to focus on this being a great experience for every backend, but certainly something we are thinking of