Re: [boost] sqlpp11, 3rd iteration

Subject: Re: [boost] sqlpp11, 3rd iteration
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-08-18 22:17:47

On 19/08/2014 09:55, Roland Bock wrote:
>> I'm guessing that the problem exists because select is lazily
>> executed. C++ objects corresponding to the data aren't created (e.g.
>> std::string, int, float, etc.). Instead some pointers to buffers are
>> kept (in sqlpp::result_field_t?). And C++ objects are created and
>> returned later from value() method or conversion operators each time
>> one of them is called. Is that right?
> Not quite. Lets look at integral.h and the partial specialization of
>
> template<typename Db, typename FieldSpec>
> result_field_t<integral, Db, FieldSpec>
> {...};
>
> 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).

Presumably it is the backend that knows whether the column/result is 
NULL or not.  Therefore it should be the backend's responsibility to 
fill in the optional correctly -- ie. you should be passing an 
address/reference to the entire optional, not the internal integer.

Otherwise how does the backend return a NULL value?