Re: Endorsement, review manager sought for Boost.Mysql

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2021-03-11 18:30:29

On Thu, 11 Mar 2021 at 12:27, Kostas Savvidis via Boost <
boost_at_[hidden]> wrote:

>
>
> > On Mar 10, 2021, at 17:34, Richard Hodges via Boost <
> boost_at_[hidden]> 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:
> >>> 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.
>
> In C and C++ we have implicit promotion rules, usual arithmetic
> conversions, and what not.
> Headache, yes for sure, but I will conjecture that bringing any SQL
> integer type, even unsigned, and treating it as int64_t
> does not violate any standard and thus is not an issue of correctness.
>

Signed types are represented as int64_t and unsigned integers as uint64_t,
to guarantee there is no overflow in any case.

>
> However, I would like to enquire of the author about the treatment of the
> following:
>
> 1) Section 11.1.4 - Floating-Point Types
> SQL allows to specify floating point precision p as FLOAT( p )- do you
> respect columns with p != 24 or 53?
>

Yes, this library does support any FLOAT(p) types. Note however that MySQL
does a quite simplistic handling
here - it just uses p to determine storage size. If p <= 23, you get a
float, else you get a double.
This page
<https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html>
provides more info.

Still, we have automated integration tests for such cases. This file
<https://github.com/anarthal/mysql/blob/master/test/integration/db_setup.sql>
contains the source code for the database types
that are part of this library's CI builds - if you spot something missing
please let me know.

>
> 2) Section 11.1.6 - UNSIGNED is allowed in MySQL even on floating point
> types - what do you do when you insert into such a column?
>

First of all, I haven't done an awful lot of tests here because MySQL has
deprecated the feature. As far as I know, MySQL
treats such a type like a regular FLOAT, but will restrict your range to
only positive values.

I don't do any special handling here. I don't have integration tests for
this particular case, but the errors are generated server-side,
so I don't think it should cause any problem. I would expect
connection::query() or prepared_statement::execute() to fail
with the corresponding MySQL error code if you provide a negative value
here. Unsigned floats don't get a special
representation in the C++ side.

>
> 3) Section 11.1.3 talks of both DECIMAL and NUMERIC as exact values and
> MySQL works with
> up to 65 decimal digit precision, presumably doing calculations in decimal
> as well. What is this type mapped into?
>

They are represented as string values (so boost::string_view). This avoids
loosing precision in applications where
precision is critical. That string_view can be parsed and used by a
specialized library later. MySQL protocol takes this
approach (it sends DECIMAL and NUMERIC values as strings even in the
"binary protocol", used in prepared statements),
so I found it easier to just respect it.

>
> 4) Section 11.1.6 - Do you need to handle ZEROFILL?
>

It does not get any special handling, but there is a good amount of
integration testing around here to double check that none is needed.
It will just be mapped to the corresponding integer. In this case, it will
always be uint64_t, as ZEROFILL implies UNSIGNED.
You can get this sort of information using the field metadata
<https://anarthal.github.io/mysql/mysql/ref/boost__mysql__field_metadata.html>
API.

>
> 5) Some general comment about Date and Time related stuff?
>

This library supports DATE, TIME, DATETIME and TIMESTAMP. In a nutshell,
DATE is mapped to std::chrono::time_point<system_clock, days>
(where days mimics C++20 std::chrono::days definition), DATETIME and
TIMESTAMP are mapped to std::chrono::time_point<system_clock,
std::chrono::microseconds>,
and TIME is mapped to std::chrono::microseconds.

There are a couple edge cases depending on how you configured your MySQL
server, though. For reference, I would suggest reading this section
<https://anarthal.github.io/mysql/mysql/types.html> of
the documentation for these topics. If there is anything unclear, please
let me know.

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