Re: [boost] SQL: next iteration of sqlpp11

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

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.
I am fully aware that empty string and database NULL are completely
different things. I am just saying that there are a bunch of use cases
(several hundreds in the company I work for), where NULL can safely be
interpreted as a trivial value and vice versa. I can explain such cases
in more detail, if you want. They are not wrong :-)

Also, please note that there is the .is_null() method. sqlpp11 does not
hide NULL from you (that would indeed be VERY wrong).

That being said, I could of course add a conversion operator to
boost::optional where applicable. That in itself would be extremely simple.

It would take some time to get there, though, since sqlpp11 would have
to be fully aware of when exactly a value could be null. An Outer Join
for instance would turn everything into optionals. The data is
available, the logic is not complete yet.

Also, for dynamic queries (where the query's structure is not fully
known at runtime), it might very well be impossible to determine whether
something can be NULL or not. Should I turn all doubtful cases into
boost::optional? That doesn't feel right.

Regards,

Roland