From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-03-25 10:59:11
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 <vinnie.falco_at_[hidden]>
> 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