On Wed, 10 Mar 2021 at 17:28, Niall Douglas via Boost
On 10/03/2021 15:34, Richard Hodges via Boost wrote:
On Wed, 10 Mar 2021 at 16:16, Niall Douglas via Boost < boost@lists.boost.org> 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