On Thu, 11 Mar 2021 at 12:27, Kostas Savvidis via Boost < boost@lists.boost.org> wrote:
On Mar 10, 2021, at 17:34, Richard Hodges via Boost < boost@lists.boost.org> 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:
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
Thanks, Kostas
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost