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

31–40 of 91 posts

Re: ggsql: A Grammar of Graphics for SQL

#33

Post by jorin »

Really cool project! Would love to see a standard established for representing visualizations in SQL! I built a whole dashboarding tool on top of the idea: https://taleshape.com/shaper/docs/getting-started/ But Shaper takes a more pragmatic approach and just uses built in functionality to describe how to visualize the results. The most value I see with viz as SQL is that it's a great format for LLMs to specify what they want while making it easy to audit and reproduce. Just built a slack bot on top of that concept last week: https://taleshape.com/blog/build-your-own-data-analytics-sla...

Re: ggsql: A Grammar of Graphics for SQL

#36

Post by thomasp85 »

rvba wrote: post #32

1) does this alllw to export to Excel? 2) how to make manual adjustments?

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

Re: ggsql: A Grammar of Graphics for SQL

#37

Post by data_ders »

nojito wrote: post #20
georgestagg wrote: post #15

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.

plus 1 for ADBC!

Re: ggsql: A Grammar of Graphics for SQL

#38

Post by wonger_ »

nchagnet wrote: post #29
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…

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

[dead]

Re: ggsql: A Grammar of Graphics for SQL

#40

Post by lmeyerov »

This is great

We reached a similar conclusion for GFQL (oss graph dataframe query language), where we needed an LLM-friendly interface to our visualization & analytics stack, especially without requiring a code sandbox. We realized we can do quite rich GPU visual analytics pipelines with some basic extensions to opencypher . Doing SQL for the tabular world makes a lot of sense for the same reasons!

For the GFQL version (OpenCypher), an example of data loading, shaping, algorithmic enrichment, visual encodings, and first-class pipelines:

- overall pipelines: https://pygraphistry.readthedocs.io/en/latest/gfql/benchmark...

- declarative visual encodings as simple calls: https://pygraphistry.readthedocs.io/en/latest/gfql/builtin_c...

Post reply on HN