Re: Endorsement, review manager sought for Boost.Mysql

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-03-10 16:27:59

On 10/03/2021 15:34, Richard Hodges via Boost wrote:
> On Wed, 10 Mar 2021 at 16:16, Niall Douglas via Boost <boost_at_[hidden]>
> 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