Re: Endorsement, review manager sought for Boost.Mysql

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2021-03-10 21:02:11

On Wed, 10 Mar 2021 at 17:28, Niall Douglas via Boost <boost_at_[hidden]>
wrote:

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

We can definitely implement this in the future. I would also give the
variant interface, though, as there may be users with that need.

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

Just to clarify, this library will never perform that conversion for the
user. If the value you retrieved was an integer, then it will stay as an
integer. value("1") != value(1).
It may be worth looking at https://anarthal.github.io/mysql/mysql/types.html
which describes the type mappings in depth.

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

I see the integer mapping rules as C++ integer conversion rules - DB
integers just get represented
as wider integer types, which is a lossless conversion, to make the
interface easier. I wouldn't say
this is a correctness problem, but I may be wrong.

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

It is not the scope of the library. The library aims to provide an
implementation for
the MySQL protocol, not a DB abstraction. It provides the bare minimum to
use the protocol.
I think what you are proposing is definitely valuable, and I would be very
happy to enhance this
library to be used as a backend for such a project. But I don't think it's
in the scope of this library -
it's just not what the library does.

>
> Niall
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>