Re: [boost] Endorsement, review manager sought for Boost.Mysql

On 10/03/2021 15:34, Richard Hodges via Boost wrote:

On Wed, 10 Mar 2021 at 16:16, Niall Douglas via Boost wrote:

...

On 10/03/2021 14:13, Ruben Perez via Boost wrote:

...

Values are stored as variants. Having more integer types means having more options in the variant. This does two nasty effects:

I am not warm on the use of variants in this situation.

One should bind types to specifics before talking to a DB, and if those types do not match, then the operation should fail.

Interestingly I take the opposite view, from the point of view of userland utility. MySQL is often used in web environments which are fluid by nature. If the program finds a value type in the variant that is unexpected it's quite at liberty to throw an exception or abort.

I'm not warm on variants in general. I find them hugely overused in code written right now. Just because they're fashionable doesn't make them a wise choice.

In almost all applications, "1", 1 and true all mean the same thing.

Absolutely not. The *end user* may choose them to mean the same thing. The *library* must not do so.

I think there's a tradeoff here: On the one hand we'd like 100% correct programs, On the other, in a startup during initial application development, under tight constraints of time and money, perfection can be the enemy of good. It's not uncommon to have to make schema changes on the fly and it's arguably better if all the users don't have to be disconnected and have their client apps upgraded first.

Having worked in several startups in my career, I have not once found ANY sacrifice of correctness ever worth it. Those startups who insisted ended up with a buggy PoS which had to be completely rewritten, which rarely happens because the VC money runs out first. That opinion you just stated is therefore, in my opinion, equal to one major cause of why startups fail. Exactly why strict binding is important is to prevent people changing the DB schema on the fly. DB schemas are like library ABIs, you design them right, once, and from then on your ship has sailed. If people come along later wanting them to be changed in a breaking way, you tell them no. If management insist, you freshen your CV and start looking for new employment elsewhere.

I'd be in favour of seeing a later evolution of the library on this front, maybe with an easy-mode interface and a pedantic interface.

Boost has historically aimed for correctness before performance, ease of use, or anything else. Claiming that talking to DBs somehow is an exception to correctness because "it's not C++" doesn't wash with me, especially as SQL is a strictly typed language just like C++, with a near one-one mapping onto C++ types. Even if it were Python duck typing here, I'd tend towards strictness as the default design. Only if you're interfacing with weakly typed languages such as Javascript do things like variant storage, eager parsing, and how this proposed library appears to be designed, make sense to me. Instead of variants here, I'd accept a visit based interface functioning as dependency injection whereby generic code is instantiated at runtime from the DB schema. i.e. move the variant switching up to the top of logic, instead of being at the bottom. I would like to see rules about what combinations are to be banned or accepted, a bit like proposed Boost.DI has. In fact, there is not a weak argument that the proper bottom up runtime DB abstraction is written using DI, and a completely separate DB abstraction comes top down with compile time static binding. My other big objection to a Boost.MySQL is the same as that from /r/cpp, that I can't see any good reason why there shouldn't be a generic DB abstracted API suitable for at least SQLite, Postgre, and MySQL. One of many possible backends would be MySQL. I don't mind if only MySQL and SQLite backends are implemented, but point is it is cheap to design this thing right, and the current proposed library doesn't do it for no obvious reason. Any arguments about "performance" don't cut it for me like they might (weakly) for Boost.JSON, any SQL DB is very slow by definition, if you are using a DB, you can even do virtual inheritance with generates terrible codegen and it would not matter a jot. Niall