Re: [boost] sqlpp11, 3rd iteration

Subject: Re: [boost] sqlpp11, 3rd iteration
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-19 08:49:31

On 2014-08-19 14:03, Adam Wulkiewicz wrote:
> Roland Bock wrote:
>> On 2014-08-19 09:39, Gavin Lambert wrote:
>>>
>>> I think we've had a terminology clash.  By "backend" I thought you
>>> meant "the sqlpp11 class that knows how to talk to the native driver",
>>> not the native driver itself.  Of course the native driver probably
>>> won't know how to drive an optional, nor should it be expected to.
>>>
>>> There are several layers, I assume:
>>>
>>> 1. User code
>>> 2. sqlpp11 database-independent frontend
>>> 3. sqlpp11 database-specific connector
>>> 4. native database library
>> Perfectly correct :-)
>>> Between layers 3 & 4 obviously you have to use whatever the native
>>> library supports, which is unlikely to be boost::optional (but still
>>> possible in some cases).  So you might have to provide a raw int64_t
>>> pointer to the database up front, and translate from a int64_t pointer
>>> and an "is this null" method call (or a bool*) to a boost::optional
>>> when it calls you back saying the complete row is ready.  (I'm
>>> assuming this is asynchronous, otherwise it's easier.)
>> As of today, it is synchronous.
>>
>>> But between layers 1 & 2 and 2 & 3 you'd only have boost::optionals.
>> I can see the reasoning for 1&2. And I understand that it can be done
>> with 2&3 of course, but I am not sure there is a benefit.
>
> As I see it, the benefit would be the use of the standard-approved way
> of handling values that could be invalid instead of using a
> library-specific handling.
>
> But I think optionals wouldn't be safe. Correct me if I'm wrong. If
> optionals were used without a check for validity and the unexpected
> NULL value was set in the DB (maybe by mistake), it could result in
> segmentation fault. Of course assuming that the macro BOOST_ASSERT()
> wouldn't be expanded to some exception throw. This could lead to some
> security vulnerabilities in apps using this library.
I thought the whole purpose of the optional-interface was to make people
to check for validity first?

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.

[...]

Regards,

Roland

PS: I cut the rest since we are in agreement there and the number of
copies, possible RVO etc depend on implementation details which might
have to be adjusted if optional were to be used :-)