Re: boost.sqlite seeking endorsement

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2024-03-23 16:51:03

On Sat, Mar 23, 2024 at 7:49 PM Vinnie Falco <vinnie.falco_at_[hidden]> wrote:
>
> On Fri, Mar 22, 2024 at 10:51 PM Daniela Engert via Boost <boost_at_[hidden]> 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.