Boost logo

Boost :

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2021-03-10 15:34:34


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.

>
> Even for querying unknown DBs, I still find use of variants here
> inappropriate. You should be able to visit a template templated with the
> right type, sure, but that isn't your library going off and making
> parsing decisions on the behalf on the end user without them telling you
> what parsing is, for this situation.
>

This sounds like a higher level interface, which may be warranted, but I
would be sad to see the variants go.

>
> > I don't think the performance gain you may get from using 1, 2 or 4 byte
> > integers (if any) is worth it, especially in 64 bit systems.
>
> It's not about performance. It's about correctness.
>
> It's also about ease of writing code quickly (particularly in environments
where MySQL is commonly used).
In almost all applications, "1", 1 and true all mean the same thing.

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.

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.

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

-- 
Richard Hodges
hodges.r_at_[hidden]
office: +442032898513
home: +376841522
mobile: +376380212

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk