Re: [boost] sqlpp11, 3rd iteration

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

On 2014-08-19 09:39, Gavin Lambert wrote:
> On 19/08/2014 19:21, Roland Bock wrote:
>> On 2014-08-19 04:17, Gavin Lambert wrote:
>>> On 19/08/2014 09:55, Roland Bock wrote:
>>>> Now, this contains an int64_t value. The address of this value is
>>>> given
>>>> to the backend in the method bind() when fetching each result row (no
>>>> laziness here). It seems to me that I cannot replace int64_t by
>>>> boost::optional<int64_t>. For instance, I cannot call get() to obtain
>>>> the address of the value if the optional is not initialized (I
>>>> would run
>>>> into an assert).
> [...]
>>> Therefore it should be the backend's responsibility to fill in the
>>> optional correctly
>> If I had an optional in the result field, yes.
>>> -- ie. you should be passing an address/reference to the entire
>>> optional, not the internal integer.
>> Some backends have functions like this (simplified):
>>
>> void get_int_field(int index, int* retval);
>>
>> How would I interact with such an interface if I had an optional<int>?
>
> 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
>
BTW: I have proposed an open content session for CppCon to start writing
a few more instances of Layer3. Apart from making the library usable for
more people, this would also help to evaluate the pros and cons of the
interface between 2&3.

Cheers,

Roland