Re: [boost] boost.sqlite seeking endorsement

On Sat, Mar 23, 2024 at 7:49 PM Vinnie Falco wrote:

On Fri, Mar 22, 2024 at 10:51 PM Daniela Engert via Boost wrote:

...

I wouldn't characterise that as 'unreasonable' - others obviously feel the same. Because of that, a library with such capabilities that already exists: https://github.com/rbock/sqlpp11.

That is a beautiful library but I still maintain that the original request, type-safe SQL strings (and constexpr at that) is unreasonable.

The library you linked does not use SQL strings at all, it has its own EDSL. It is not actually SQL (which represents database queries using a string) but rather "sql-flavored" C++ API. Julien wanted this:

prepare("insert into author (first_name, last_name) values (?1, ?2), (?3, ?4), (?5, ?6), (?7, ?8)");

to be type-safe. Doing so would require parsing the SQL string. It is this which is unreasonable as it is reinventing the parser from sqlite.

It's not very useful either. Yes, you could check if an argument is missing, but you can never know if a query is valid at runtime, e.g. if the `author` table exists can only ever be checked at runtime. And on top of that, missing an input argument is not an error in sqlite - it's just null.

I have to ask an obvious question, why didn't the author of proposed Boost.Sqlite just start with one of these mature libraries? This sqlpp11 looks very nice, comparable to soci if not better.

I think that's because you have multiple tasks that are often done by different libraries in multiple languages. In the lowest layer (1) you have the specific database client (e.g. boost.mysql), on layer 2 a generic database client (e.g. SoCi), then a query builder on layer 3 (e.g. sqlpp11) and then you usually have ORMs in layer 4, when you have reflection in the language. boost.sqlite would be strictly layer (1) so it can support sqlite specific features. A generic database client would be great, too, especially when built on top of boost.mysql and boost.sqlite, but that's just not what boost.sqlite tries to be. So I don't see either library as contenders. The actual contenders are other sqlite client libraries in C++ and I list some in the readme. I don't think it's helpful to compare this proposed library to generic sql clients or query builders, just like it wouldn't have been helpful to compare boost.beast to python requests. Peter pointed out that it might be a good idea to add some side to side comparison of using sqlite with using my library and he's correct since this does not seem apparent. But that's the problem this library tries to solve.