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

81–90 of 91 posts

Re: ggsql: A Grammar of Graphics for SQL

#81

Post by nchagnet »

mbreese wrote: post #64
nchagnet wrote: post #29

Earlier quoted context omitted.

I was quite psyched when I read this so maybe I can tell you why it's interesting to me, although I agree the announcement could have done a better job at it. In my experience, the only thing data fields share is SQL (analysts, scientists and engineers). As you said, you could do the same in R, but your project may not be written in R, or Python, but it likely uses an SQL database and some engine to access the data.…

But isn't this then just another tool that you're including in your project? I don't get why I would want to add this as a visualization tool to a project, if it's already using R, or Python, etc... I mean, is it to avoid loading the full data into a dataframe/table in memory? I just don't see what the pain point this solves is. ggplot solves quite a lot of this already, so I don't doubt that the authors know the dom…

Well there's always going to be a dependency anyway: loading the data, making it a dataframe, visualizing it, this might be 3 libraries already.

In a sense I really get your complaint. It's the xkcd standard thing all over, we now have a new competing standard.

I think for me it's not so much the ggplot connection, or the fact that I won't need a dataframe library.

It's that this might be the first piece of a standard way of plotting: no matter which backend (matplotlib, vega, ggplot), no matter how you are getting your data (dataframes, database), where you're doing this (Jupyter or marimo notebook, python script, R, heck lokkerstudio?). You could have just one way of defining a plot. That's something I've genuinely dreamt about.

And what makes this different from yet another library api to me is that it's integrated within SQL. SQL has already won the query standardisation battle, so this is a very promising idea for the visualization standardisation.

Re: ggsql: A Grammar of Graphics for SQL

#82

Post by mstr_anderson »

getnormality wrote: post #19

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 betwe…

[flagged]

Re: ggsql: A Grammar of Graphics for SQL

#83

Post by [deleted] »

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…

[deleted]

Re: ggsql: A Grammar of Graphics for SQL

#85

Post by lioeters »

nchagnet wrote: post #81
mbreese wrote: post #64

Earlier quoted context omitted.

But isn't this then just another tool that you're including in your project? I don't get why I would want to add this as a visualization tool to a project, if it's already using R, or Python, etc... I mean, is it to avoid loading the full data into a dataframe/table in memory? I just don't see what the pain point this solves is. ggplot solves quite a lot of this already, so I don't doubt that the authors know the dom…

Well there's always going to be a dependency anyway: loading the data, making it a dataframe, visualizing it, this might be 3 libraries already. In a sense I really get your complaint. It's the xkcd standard thing all over, we now have a new competing standard. I think for me it's not so much the ggplot connection, or the fact that I won't need a dataframe library. It's that this might be the first piece of a standar…

I see, that's insightful. At first sight I thought of it as a kind of novelty, extending SQL with a visual grammar to integrate with a specific plotting library. But from your comments I can now imagine it has potential as a general solution for that space between data - wherever it comes from, it can typically be queried by SQL - and its visualization.

Thinking further, though, there might be value in extracting the specs of this "grammar of graphics" from SQL syntax and generalized, so other languages can implement the same interface.

Re: ggsql: A Grammar of Graphics for SQL

#86

Post by RobinL »

georgestagg wrote: post #57
tmoertel wrote: post #53

First, ggsql looks awesome. Can't wait to try it out. Feedback: A notable omission in the ggsql docs: I cannot find any mention of the possible outputs. Can I output a graphic in PDF? In SVG? PNG? How do I control things like output dimensions (e.g., width=8.5in, height=11in)? The closest I got was finding these few lines of example code in the docs for the Python library: # Display or save chart.display() # In Jupyt…

Currently our only writer module is for vegalite, the output is a vegalite spec (JSON). Tools already exist to render this kind of output to an interactive chart, SVG, PNG, etc. with their own controls for sizing and the like. Our ggsql Jupyter kernel can use these vegalite specifications to output charts in a Quarto document, for example. In the future we plan to create a new high performance writer module from scra…

Please retain vega lite speech as an option! It's incredible useful because you can tweak the chart or change it completely at a later date using e.g. the vega lite editor.

Re: ggsql: A Grammar of Graphics for SQL

#87

Post by anentropic »

tantalor wrote: post #27
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…

> SQL databases ... confused "SQL" and "databases" are different things SQL is a declarative language for data manipulation. You can use SQL to query a database, but there's nothing special about databases. You can also write SQL to query other non-database sources like flat files, data streams, or data in a program's memory. Conversely, you can query a database without SQL.

thanks Captain Obvious, where would we be without you

Re: ggsql: A Grammar of Graphics for SQL

#88

Post by nchagnet »

lioeters wrote: post #85
nchagnet wrote: post #81

Earlier quoted context omitted.

Well there's always going to be a dependency anyway: loading the data, making it a dataframe, visualizing it, this might be 3 libraries already. In a sense I really get your complaint. It's the xkcd standard thing all over, we now have a new competing standard. I think for me it's not so much the ggplot connection, or the fact that I won't need a dataframe library. It's that this might be the first piece of a standar…

I see, that's insightful. At first sight I thought of it as a kind of novelty, extending SQL with a visual grammar to integrate with a specific plotting library. But from your comments I can now imagine it has potential as a general solution for that space between data - wherever it comes from, it can typically be queried by SQL - and its visualization. Thinking further, though, there might be value in extracting the…

I completely agree, and I think this is also where I'm quite excited. This project's connection with ggplot , which has one of the most respected grammar for plotting, means that it would be in a good position to achieve what you describe.

Re: ggsql: A Grammar of Graphics for SQL

#89

Post by jochapjo »

ggsql looks great for Posit's ecosystem (ggplot2 and plotnine). However, you can make the language more "SQL-like" by making some adjustments to the underlying grammar of graphics. I wrote a paper about a SQL-like language based on the grammar of graphics awhile back that discusses this, https://arxiv.org/pdf/2505.14690. The language is called SGL. I sent an early version of the paper to Hadley (Posit) a couple of years ago - the language has enough similarities that I assume they were influenced by it and developed a version catered to their ecosystem. For SGL (not ggsql) in particular, there will be implementations available this year that aren't catered to Posit's ecosystem.

Re: ggsql: A Grammar of Graphics for SQL

#90

Post by sinnsro »

Zedseayou wrote: post #77
sinnsro wrote: post #73

Earlier quoted context omitted.

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

I fail to see your point, as the base pipes can be combined with blocks and wrapping the target function into another function.

Although, IMHO, if that many operations are crammed into a single pipe pass, then something is amiss.

Post reply on HN