Re: [boost] Review of Boost.MySql

On Wed, 11 May 2022 at 09:54, Julien Blanc via Boost 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_optio... https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_optional....

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() 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(); // 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