Re: [boost] SQL: next iteration of sqlpp11

Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Roland Bock (rbock_at_[hidden])
Date: 2014-02-04 14:17:03

On 2014-02-04 19:56, Edward Diener wrote:
> On 2/4/2014 2:05 AM, Roland Bock wrote:
>> On 2014-02-03 17:33, Edward Diener wrote:
>>> On 2/3/2014 10:03 AM, Roland Bock wrote:
>>>> On 2014-02-03 14:50, Bjorn Reese wrote:
>>>>> Table columns have a _can_be_null option. How about handling this
>>>>> implicitly by declaring the _value_type be a boost::optional type?
>>>>>
>>>>>
>>>> Hi Bjorn,
>>>>
>>>> I thought about using boost::optional for some time, but decided
>>>> against
>>>> it for the time being.
>>>>
>>>> In most usecases I encountered so far, it is totally OK to interpret
>>>> NULL values like default values, e.g. NULL strings and empty
>>>> strings, or
>>>> NULL foreign keys or 0LL. For those usecases it would be quite
>>>> annoying
>>>> to have to check if there really is a value, or always use
>>>> get_optional_value_or...
>>>
>>> You are wrong ! Having a database NULL value is completely different
>>> from having an empty string or a 0 value. Please reconsider. The
>>> boost::optional is the correct choice.
>>
>> Edward,
>>
>> after a short night's sleep I drafted a document for how sqlpp11 could
>> cover both use cases:
>>
>>   1. NULL is NULL and nothing else, dammit!
>>   2. NULL or 0? Sometimes I just don't care.
>>
>> https://github.com/rbock/sqlpp11/wiki/NULL
>>
>>
>> Please let me know what you think.
>
> This is strictly my preference but I think it would be much easier and
> cleaner if all values, as objects, passed to and returned from a
> database were boost::optional<T> values for the particular type T of a
> column. That way the possibility that a column could hold a DB NULL
> value would be fully taken care of and it is now up to the end-user to
> realize that a DB NULL could be a valid value and deal with it
> accordingly.
>
I admit that the idea of using boost::optional (or something very
similar) not only for select results but also for values in statements
is growing on me. It seems like a nice symmetry indeed. I'll spend some
time letting it sink (and I also need to think about how to handle my
own use case elegantly).

Thanks and regards,

Roland