On 2020-03-05 10:02, Julien Blanc via Boost wrote:
Le mercredi 04 mars 2020 à 16:06 +0000, Paul A Bristow via Boost a écrit :
It seems a no-brainer to me that a well maintained means of efficiently doing so would be a positive addition to boost.
By itself, this is a reasonably convincing case, but what would quiet some of doubters would be to have at least an outline of connecting to another database. Showing reasonable confidence that extension to other databases is feasible would be a big plus IMO.
I expect a more versatile db library to rely on underlying low-level backends such as this one, so i tend to disagree here: trying to handle multiple database here will greatly increase complexity with few additional value for the user: differences in SQL dialects and supported types, for example, will anyway prevent any simple backend switch for the user.
Having a common shared design for the different backends, however, will indeed be useful in building a higher level db abstraction, though (not sure if it was your point).
Right. But when the backends are not part of a common solution, I have a hard time seeing them have a compatible interface, which makes writing the higher level unifying library more difficult and the end result less efficient. Granted, you will have the same kind of problems when using the native C APIs of database engines. But my point is that the solution that is designed from the start as a unifying frontend + multiple backends from the start has the potential of being more efficient and more straightforward.