Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ggsql: A Grammar of Graphics for SQL

opensource.posit.co

Post reply on HN
Print view View original

11–20 of 91 posts

Re: ggsql: A Grammar of Graphics for SQL

#11

Post by password4321 »

anentropic wrote: post #9

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 databases I 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.html But then https://ggsql.org/faq.html has a section…

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.

Re: ggsql: A Grammar of Graphics for SQL

#12

Post by thomasp85 »

anentropic wrote: post #9

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 databases I 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.html But then https://ggsql.org/faq.html has a section…

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 smooth

will 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

Re: ggsql: A Grammar of Graphics for SQL

#13

Post by thomasp85 »

password4321 wrote: post #11
anentropic wrote: post #9

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 databases I 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.html But then https://ggsql.org/faq.html has a section…

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.

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

Re: ggsql: A Grammar of Graphics for SQL

#15

Post by georgestagg »

anentropic wrote: post #9

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 databases I 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.html But then https://ggsql.org/faq.html has a section…

ggsql has the concept of a "reader", which can be thought of as the way ggsql interfaces with a SQL database. It handles the connection to the database and generating the correct dialect of SQL for that database.

As an alpha, we support just a few readers today: duckdb, sqlite, and an experimental ODBC reader. We have largely been focusing development mainly around driving duckdb with local files, though duckdb has extensions to talk to some other types of database.

The idea is that ggsql takes your visualisation query, and then generates a selection of SQL queries to be executed on the database. It sends these queries using the reader, then builds the resulting visualisation with the returned data. That is how we can plot a histogram from very many rows of data, the statistics required to produce a histogram are converted into SQL queries, and only a few points are returned to us to draw bars of the correct height.

By default ggsql will connect to an in-memory duckDB database. If you are using the CLI, you can use the `--reader` argument to connect to files on-disk or an ODBC URI.

If you use Positron, you can do this a little easier through its dedicated "Connections" pane, and the ggsql Jupyter kernel has a magic SQL comment that can be issued to set up a particular reader. I plan to expand a little more on using ggsql with these external tools in the docs soon.

Re: ggsql: A Grammar of Graphics for SQL

#19

Post by getnormality »

I skimmed the article for an explanation of why this is needed, what problem it solves, 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 first pull the data into R data frames so we can run ggplot on it? But why create a new SQL-like language? We already have a package, dbplyr, that translates between R and SQL. Wouldn't it be more direct to extend ggplot to support dbplyr tbl objects, and have ggplot generate the SQL?

Or is the idea that SQL is such a great language to write in that a lot of people will be thrilled to do their ggplots in this SQL-like language?

EDIT: OK, after looking at almost all of the documentation, I think I've finally figured it out. It's a standalone visualization app with a SQL-like API that currently has backends for DuckDB and SQLite and renders plots with Vegalite. They plan to support more backends and renderers in the future. As a commenter below said, it's supposed to help SQL specialists who don't know Python or R make visualizations.

Re: ggsql: A Grammar of Graphics for SQL

#20

Post by nojito »

georgestagg wrote: post #15
anentropic wrote: post #9

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 databases I 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.html But then https://ggsql.org/faq.html has a section…

ggsql has the concept of a "reader", which can be thought of as the way ggsql interfaces with a SQL database. It handles the connection to the database and generating the correct dialect of SQL for that database. As an alpha, we support just a few readers today: duckdb, sqlite, and an experimental ODBC reader. We have largely been focusing development mainly around driving duckdb with local files, though duckdb has e…

Highly suggest leveraging adbc. I would love to use this against our bigquery tables.
Post reply on HN