Live data from Hacker News

Instant SQL for results as you type in DuckDB UI

motherduck.com

91–100 of 124 posts

Re: Instant SQL for results as you type in DuckDB UI

#91
post #88
post #2

In DuckDB UI and MotherDuck. Awesome video of feature: https://youtu.be/aFDUlyeMBc8 Disclaimer: I’m a co-founder at MotherDuck.

This is probably stupid, but at the hope of helping others through exposing my own ignorance -- I'm having trouble actually installing and running the preview... I've downloaded the preview release duckdb binary itself, then when I try to run "duckdb -ui", I'm getting this error: Extension Autoloading Error: An error occurred while trying to automatically install the required extension 'ui': Failed to download extens…

Sorry you hit that! This is actually already working on version 1.2.2. Could you install that version? That should get you going for the moment! We will dig into what you ran into.

Re: Instant SQL for results as you type in DuckDB UI

#93
post #92

it looks cool, but i wish i could just see the entire table that im about to query. i always start my queries with a quick `select * from table limit 10;` then go about adding the columns and joins

`from my_table`

will do the same!

We are working on how to make it easy to switch from instant sql -> run query -> instant sql

Re: Instant SQL for results as you type in DuckDB UI

#94

I really like duckdb's notebooks for exploration and this feature makes them even more awesome, but the fact that I can't share, export or commit them into a git repo feels extremely limiting. It's neat-ish that it dodfoods and store them in a duckdb database. It even seems to stores historical versions, but I can't really do anything with it..

You can try marimo notebooks, which are stored as pure Python and support SQL cells through duckdb. (I’m one of its authors.)

https://github.com/marimo-team/marimo

Re: Instant SQL for results as you type in DuckDB UI

#95

It would be even better if SQL had pipe syntax. SQL is amazing, but its ordering isn’t intuitive, and only CTEs provide a reliable way to preview intermediate results. With pipes, each step could clearly show intermediate outputs. Example: FROM orders |> WHERE order_date >= '2024-01-01' |> AGGREGATE SUM(order_amount) AS total_spent GROUP BY customer_id |> WHERE total_spent > 1000 |> INNER JOIN customers USING(custome…

that syntax is horrendous.

Re: Instant SQL for results as you type in DuckDB UI

#96

It would be even better if SQL had pipe syntax. SQL is amazing, but its ordering isn’t intuitive, and only CTEs provide a reliable way to preview intermediate results. With pipes, each step could clearly show intermediate outputs. Example: FROM orders |> WHERE order_date >= '2024-01-01' |> AGGREGATE SUM(order_amount) AS total_spent GROUP BY customer_id |> WHERE total_spent > 1000 |> INNER JOIN customers USING(custome…

While I would certainly agree with you that putting the FROM clause first would be a significant improvement to SQL and was a genuine design mistake, this otherwise feels more like just wanting SQL to be less declarative and more imperative. Wanting it to be more like LINQ and less like relational algebra.

That, I think, is most developers' real sticking point with SQL. It's not object-relational impedance mismatch between their application and the data store, it's imperative-declarative impedance mismatch between their preferred or demonstrated talent. They are used to thinking about problems in exactly one way, so when they struggle to adapt to a different way of thinking about the problems they assume their familiarity is what's more correct.

I think this is why the same developers insist that XML/HTML is "just a markup language." Feeding a document into an executable to produce output isn't really significantly different than feeding imperative language into a compiler. The only real difference is that one is Turing complete, but Turning completeness is not a requirement of programming languages.

Re: Instant SQL for results as you type in DuckDB UI

#100
post #41

Earlier quoted context omitted.

No, it comes from wanting to make autocompletion easier and to make variable scoping/method ordering make sense within LINQ. It is an actual improvement in this regard. LINQ popularized it and others followed. It does what it says. Btw: saying that "people try to impose their own comfort" is uncalled for.

In that case you are just objectively incorrect, you can build a far, far more efficient autocomplete in the standard query order. I will guess something like half as many keystrokes to type the same select and from clauses. You are imagining a very niave autocomplete that can only guess columns after it knows the tables, but in reality you can guess most of the columns, including the first one, the tables, and the a…

I don’t want to type any column names. When you start with FROM the only autocomplete suggestions available are the columns from the specific table, not the entire database. How many columns do I need to type before you can single down a single table? What if you have multiple tables with the same column names?
Post reply on HN