Re: [boost] sqlpp11, 3rd iteration

Subject: Re: [boost] sqlpp11, 3rd iteration
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-21 08:58:27

On 2014-08-21 12:32, Bjorn Reese wrote:
> On 08/19/2014 02:49 PM, Roland Bock wrote:
>
>> If I understand you correctly, you should be more happy with the current
>> implementation then: As of today, depending on the compile-time
>> configuration in the connector you have the following possible
>> behaviors:
>>
>> You can always check for NULL by calling is_null. But if you ignore the
>> outcome and try to obtain the value of a field which happens to be NULL
>>
>> Variant A: an exception is thrown
>> Variant B: the "trivial" value is returned, 0 for numbers.
>>
>> The Variant is chosen at compile time.
>
> I find it a bit worrying that this behavior is changeable at
> compile-time, as it makes reviewing and reuse more challenging.
The decision is taken in the connector class or the respective column.
If you change those, you will have some effect.

Also, it would be easy to make your code break at compile time if you
switch between A and B. It already breaks if you use B in the typical
way (see below) and switch to A.

Thus, you would not get nasty surprises after compilation.
>
> With optional<T> you will get variant A. If you want variant B, then
> you use optional<T>::value_or(). This makes your intent clear in the
> code.
_Variant A is (as of today):_
if (!row.alpha.is_null())
{
   int a = row.alpha.get_value();
}
else
{
   // something else
}

_Variant B is:_
int a = row.alpha;

The conversion operator to the respective value type is not available in
Option A.

I am using Variant B all over the place. If I had to change all that into

int a = row.alpha.get_value_or(0);

I would have to add kilobytes of noise, lowering readability, IMO.

Since I personally do not use Variant A, I am open for suggestions, of
course :-)

Cheers,

Roland