On Fri, Mar 22, 2024 at 11:14 PM Daniele Lupo via Boost
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!