Re: Review of Boost.MySql

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2022-05-12 07:54:32

On Wed, 11 May 2022 at 09:54, Julien Blanc via Boost
<boost_at_[hidden]> wrote:
>
> Le 2022-05-10 22:33, Marcelo Zimbres Silva via Boost a écrit :
>
> > 6) ================================
> >
> >> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_std_optional.html
> >> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_optional.html
> >
> > Sounds also unusual to have two member functions for the different
> > versions of optional. I suggest using the boost version until we
> > transition to C++17.
>
> I probably won't have the time to do a proper review, but had a quick
> look at the documentation and this interface surprised me a bit. I was
> expecting optional (whether std or boost) to be used to map nullable
> values, but it seems that's not the case. It seems this interface will
> return an empty optional if using a wrong type (like trying to get an
> int from a string column), but the doc is silent on what it will do if
> trying to get an int from a nullable int which is actually NULL (my
> understanding is that it would return an empty optional). It bothers me
> a bit that these two use cases are handled the same way, because one of
> them is a valid use, and the other is a mismatch between the program and
> the database schema that i would like to diagnose.

That's right, value::get_optional<uint64_t>() will return an empty optional
either if your value is not an int (e.g. an string) or an actual NULL value.
You can distinguish both using value::is_null(). For the use case you are
proposing, I would suggest this kind of code:

value v = /* get your value */
if (v.is_null())
{
    // handle NULL case
}
else
{
    uint64_t my_int = v.get<uint64_t>(); // This will throw on type mismatch
}

Of course, if we end up implementing reading rows into compile-time known
data structures, we can do a better job here.

>
> I understand this issue is non-trivial, since when the value is
> retrieved from the row object, the information about the type of the
> data in the DB (and thus its nullability) is lost. However, it seems
> odd. It may be of interest to store whether the field is null in a
> independent way from its type, instead of relying on a single null type.

Additionally to value::is_null, you can also access field metadata
using resultset.fields()[index]. This returns a field_metadata object
https://anarthal.github.io/mysql/mysql/ref/boost__mysql__field_metadata.html
which contains a is_not_null() function, which will return true if you
created your field with a NOT NULL clause.

>
> Or maybe i just missed something obvious.
>
> Regards,
>
> Julien
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost