Watching a video pointing to other videos of how this query generator works is probably a lot like using it to generate queries.

Wish I could bill time for youtubing but I'm busy writing schema and queries I fully understand.

It took WAY too many hops to figure out what this thing even is.

I assume that they're going for a very specific audience (i.e. people who regularly write SQLite extensions in C code). And don't have much interest in reading a broader audience, of people who don't currently write SQLite extensions but might find it valuable if made more accessible.

A tech tool should have SOME code snippet on the main page, giving some idea of context at an immediate glance. This isn't hard. Don't have your main page be a YouTube video introducing other YouTube videos, and your "Docs" section contain zero code because that's actually tucked away somewhere else.

> It took WAY too many hops to figure out what this thing even is.

This is why I'm never done with documentation until I've watched at least two users try to do something productive with it. I'm very sensitive to the idea of circular reasoning. I still do it without noticing, and I'm someone who cares. People who don't care at all are much worse.

Feeling sympathy for an imaginary person in your head will never work as well as feeling sympathy for an actual struggling human.

> write stored procedures in a variant of Transact-SQL (T-SQL) and compile them into C code that uses SQLite’s C API

MIT C from Facebook

This seems like offshoot tech from the Facebook messenger rewrite that claimed to lower as much as possible to the database for cross-platform sharing - https://engineering.fb.com/2020/03/02/data-infrastructure/me...

The proposed architecture seems cool, until you realize that instead of writing the languages your mobile devs know, instead you end up writing a lot of C (or generating a lot of C) to be cross platform, and the overlap of C developers and mobile / consumer-oriented developers in Silicon Valley is quite slim. I heard through the grapevine that the success of that rewrite was greatly overstated and it turned into a pain quite quickly.

All that said, I have a cross-platform app using SQLite… and I’m okay with C… maybe I can con the mobile team at my company into using this to ensure more job security?

Lots of compilers compile to C as a target without requiring any C knowledge of the developer. C is an implementation detail.

Why use C instead of an ORM framework for your favourite language?

C + SQLite works equally well for native code on iOS, Android, and WASM

You can also try it online here https://mingodad.github.io/CG-SQL-Lua-playground/ using the Lua language.

Haha wow CSS in the output definitely caught me off guard https://cgsql.dev/docs/playground

That looks like syntax highlighting for the query plan

Man, in that video, she said "easy" or "simple", but shit sounded complicated real fast.

Yeah, it's the curse of expertise. Unfortunately after a certain point of expertise it becomes hard to get a feeling what for what is easy or hard for understand for laymen. I remember a professor complaining that every year the exam questions he thought were easy were often the questions his students got wrong, while the exam questions he thought were hard were the ones his students got right.

As in: “Just Simply – Stop saying how simple things are in our docs ” - posted 19 days ago here on HN -

https://news.ycombinator.com/item?id=35759449

Bizarre how people do that.

Looks like this is similar to what Cython is for Python?

So this variant of T-SQL runs as fast as C right?

It gets turned into C, so yes.

>The generated code always checks the various return codes and always uses the correct column ordinals and column types when binding or reading data to or from the SQLite system — areas that are notoriously difficult to get right and keep right.

If you care mostly about this part, and are using C++20, you can use meta programming to accomplish this with some annotations of your SQL statements, and avoid code generators and separate syntax.

https://github.com/google/cpp-from-the-sky-down/blob/master/...

        ftsd::prepared_statement<
                "INSERT INTO orders(item , customerid , price, discount_code ) "
                "VALUES (?/*:item:text*/, ?/*:customerid:integer*/, ?/*:price:real*/, "
                "?/*:discount_code:text?*/ );"  //
        >
                insert_order{sqldb};

        insert_order.execute({bind<"item">("Phone"), bind<"price">(1444.44),
        bind<"customerid">(customer_id)});
        insert_order.execute({bind<"item">("Laptop"), bind<"price">(1300.44),
        bind<"customerid">(customer_id)});
        insert_order.execute({bind<"customerid">(customer_id), bind<"price">(2000),
                bind<"item">("MacBook"),
                ftsd::bind<"discount_code">("BIGSALE")});
 

You can bind the parameters in any order, as long as the names are correct. If you don't bind any non-optional parameters or have the incorrect type, you will get a compile time error.

My talk going over how to implement this: https://youtu.be/1AYrd9iLQCw

who in their right mind would trust this shit on a production database?

People who write tests for the OSS they use?