Re: [boost] boost.sqlite seeking endorsement

Le dimanche 24 mars 2024 à 00:51 +0800, Klemens Morgenstern via Boost a écrit :

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

...

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.

That's right, but to be honest i did not expected it to be true. However, the kind of reply i expected was like "No, it won't, but you can achieve a similar result by X". I see it's more "it's well outside the scope of the library" (which is fine as well, just not attracting my attention).

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.

Allow me to disagree here: everything you can catch sooner than later, is useful.

And on top of that, missing an input argument is not an error in sqlite - it's just null.

I wasn't aware of that. But it just feels plain wrong.

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 agree with that. However, sqlite c++ wrappers have been here for ages, what's making the proposed boost.sqlite different from existing libraries? It's not so clear to me. I see two things that are not widespread: * variant-base interface * json support Did i miss others ?

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.

Another useful addition would be side-by-side comparison with sqlitecpp. As i understand from the docs, boost.sqlite has a few more features. Are the missing features what made the author start its own library? Regards, Julien