Re: boost.sqlite seeking endorsement

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2024-03-22 15:28:58

On Fri, Mar 22, 2024 at 11:14 PM Daniele Lupo via Boost
<boost_at_[hidden]> wrote:
>
> Hi.
>
> The idea seems good, but I've a bit worried about it.
>
> We already have a boost mysql library, and a redis library. Now we want
> to introduce a sqlite library, and maybe tomorrow a keydb library, a
> dragonfly library, a postgres library, a db2 library and so on...

I don't understand the worry. Boost could supply different db clients
that all follow best practices.

>
> I mean, this is a lot of fragmentation, for tools that are, in my
> opinion, tiny wrappers over native connection libraries, and thich the
> purpose is the same, executing queries. What's the big advantage of
> using those libraries instead than native ones?
>
/snip
>
> This sqlite library does not seems to have any real advantage if we see
> official ones, and I'm convinced that if we'll develop it we'll have
> another library that does not add any feature but boost asio and
> coroutines native support. If we create it, we'll have another library
> that's specific for a specific tool.
>

That is a fair criticism. An sqlite wrapper is much more limited in scope,
since it doesn't add support for asynchronicity (since sqlite is not async).

However, when using sqlite directly from C++, you'll end up with loads
of boilerplate
and boost.sqlite would solve that problem. It does not add support for
asio or coroutines.

> Maybe in this case the right repository is not boost, but the tool's
> one. Maybe if we want to support sql and no-sql databases, it's worth to
> think to a general solution, like Qt Sql library, that with a unique
> interface we can use different databases?
>

I think this would be great, but I would prefer it that would be a
layer above mysql & sqlite (and future libraries).
That is a boost.sql library should use the available boost sql
libraries itself to provide such an interface.

> I don't like Qt Sql for other reasons (plugins, moc, etc.), but the
> general idea is good. If we want to pollute boost with a lot of
> libraries that do the same thing (execute queries) with different
> programs (sqlite, mysql, redis etc), maybe it's better to stop a think a
> bit about a more general solution, a single library that embrace them
> all. Because this way we can have a unique library and interface for
> linking to a specific repository by using coroutines and asio, and give
> to detail implementation, or custom plugins, the effort to link the
> library to a specific tool. We already have boost libraries that can
> have external dependencies, for example Locale that can use ICU, or
> Odeint. This will be no different from those ones.
>

I like the sentiment, but I wonder if it's even possible to solve the
general problem here. Many ORMs have tried and I can't think of one
that succeeded.

> Obviously, those are my two cents.
>
I appreciate it!