Re: boost.sqlite seeking endorsement

From: Daniele Lupo (jepessen_at_[hidden])
Date: 2024-03-22 15:05:07

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 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?

If I see the documentation of boost mysql and boost redis I can see that 
the "only" advantage of using them instead of native libraries is 
supporto for ASIO and coroutines. I can suppose that's a real advantage 
by your feedback, I never used them and I'm not using asio at the moment.

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.

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 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.

Obviously, those are my two cents.

Regards

Daniele Lupo