Live data from Hacker News

ggsql: A Grammar of Graphics for SQL

opensource.posit.co

71–80 of 91 posts

Re: ggsql: A Grammar of Graphics for SQL

#71
Would be quite compelling if the CLI worked with nushell.

I see the (a?) backend is polars, which is good as well.

This in CLI might be the quickest / tersest way to go from "have parquet / csv / other table format" to "see graph", though a keen polars / matplotlib user would also get there pretty quick.

Re: ggsql: A Grammar of Graphics for SQL

#73

I applaud the project, and I completely agree that the concepts maps nicely to SQL. The R equivalent of a WITH data prep block followed by the VISUALIZE is pretty much how all my plotting code is structured. However, I don't see what the benefits of this are (other than having a simple DSL, but that creates the yet another DSL problme) over ggplot2. What do I gain by using this over ggplot2 in R? The only problem, an…

Side comment: |> and %>% aren't the same btw! The newish base pipe (|>) is faster but doesn't support using the dot (.) placeholder to pipe into something other than the first argument of a function, which can sometimes make things a little cleaner.

The base pipe has an underscore as a placeholder. From the docs:

Usage:

     lhs |> rhs
Arguments:

     lhs: expression producing a value.

     rhs: a call expression. 
Details: [...]

     It is also possible to use a named argument with the placeholder
     ‘_’ in the ‘rhs’ call to specify where the ‘lhs’ is to be
     inserted.  The placeholder can only appear once on the ‘rhs’.

Re: ggsql: A Grammar of Graphics for SQL

#74

Earlier quoted context omitted.

So we could use this with Postgres by putting DuckDB in front with its Postgres extension, pointing to the source data in PG?

In principle, yes, that’s the idea! However I will say we have focused mainly on the grammar and using DuckDB for reading from local files for this alpha release, so I expect there may be some bugs around connecting to remote databases still to iron out!

Dunno, I expect if DuckDB works as advertised it might just work! That's the beauty of how they've separated the syntax parsing into frontend/backend from the rest of the engine.

Re: ggsql: A Grammar of Graphics for SQL

#75

I applaud the project, and I completely agree that the concepts maps nicely to SQL. The R equivalent of a WITH data prep block followed by the VISUALIZE is pretty much how all my plotting code is structured. However, I don't see what the benefits of this are (other than having a simple DSL, but that creates the yet another DSL problme) over ggplot2. What do I gain by using this over ggplot2 in R? The only problem, an…

We are not out to convince anyone to switch from ggplot2 (and we are not planning to stop developing that). ggsql is (partly) about reaching new audiences and putting powerful visualisation in new places. If you live in R most of the time I wouldn't expect you to be the prime audience for this (though you may have fun exploring it since it contains some pretty interesting things ggplot2 doesn't have)

Totally get that. I was mostly just long-windedly complaining that the one problem I have with it seems to be exacerbated by, not fixed, by this. I was also hoping someone would say “oh it’s actually way easier than you think, see (amazing link).”

I really do think it’s a good idea to explore! Sometimes I feel crazy because I’m the only one in my department that prefers to just write SQL to deal with our DBs instead of fiddling with a python/R connector that always has its own quirks.

Re: ggsql: A Grammar of Graphics for SQL

#76
This is amazing work. I've always wanted to be able to make visualizations straight from a SQL REPL. I've been thinking about building something sort of like this with Perspective[1] + DuckDB. Perspective would give an interactive chart (and/or wicked datagrid), and using a Perspective virtual server, you could feed filter + pivot conditions in the UI back to the database query. Maybe this is the kick I need to get this out of ideation.

[1]: https://perspective-dev.github.io/

Re: ggsql: A Grammar of Graphics for SQL

#77
post #73

Earlier quoted context omitted.

Side comment: |> and %>% aren't the same btw! The newish base pipe (|>) is faster but doesn't support using the dot (.) placeholder to pipe into something other than the first argument of a function, which can sometimes make things a little cleaner.

The base pipe has an underscore as a placeholder. From the docs: Usage: lhs |> rhs Arguments: lhs: expression producing a value. rhs: a call expression. Details: [...] It is also possible to use a named argument with the placeholder ‘_’ in the ‘rhs’ call to specify where the ‘lhs’ is to be inserted. The placeholder can only appear once on the ‘rhs’.

I believe this wasn't added in the initial implementation of the base pipe so some didn't realize it got included later, and still does not let you use constructs like e.g. combining multiple transformations of the input on the rhs. But for most purposes it's certainly sufficient

Re: ggsql: A Grammar of Graphics for SQL

#78

I applaud the project, and I completely agree that the concepts maps nicely to SQL. The R equivalent of a WITH data prep block followed by the VISUALIZE is pretty much how all my plotting code is structured. However, I don't see what the benefits of this are (other than having a simple DSL, but that creates the yet another DSL problme) over ggplot2. What do I gain by using this over ggplot2 in R? The only problem, an…

> What do I gain by using this over ggplot2 in R?

You don't have to use R.

Re: ggsql: A Grammar of Graphics for SQL

#79
post #62

Earlier quoted context omitted.

My answers will probably disappoint 1) No (unless you count 'render to image and insert that into your excel document') 2) This is not possible - manual adjustments are not reproducible and we live by that ethos

What makes ggplot great is that it allows manual adjustments AND has a nice declerative grammar. Hard for me to see the value of a plotting library without being able to adjust plots.

You’ll be able to adjust plots. But you have to do it with code, not UI.

Re: ggsql: A Grammar of Graphics for SQL

#80
post #20

Earlier quoted context omitted.

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.

Another +1 for ADBC
Post reply on HN