Re: [boost] SQL: next iteration of sqlpp11

Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-02-04 13:56:14

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.