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 13:02:15

On 2014-02-03 18:36, Johan Baltié wrote:
> On Mon, Feb 3, 2014 at 6:27 PM, Roland Bock <rbock_at_[hidden]> wrote:
>
>> On 2014-02-03 18:22, Johan Baltié wrote:
>>> On Mon, Feb 3, 2014 at 5:56 PM, Klaim - Joël Lamotte <mjklaim_at_[hidden]
>>> wrote:
>>>
>>>> On Mon, Feb 3, 2014 at 5:33 PM, Edward Diener <eldiener_at_[hidden]
>>>>> wrote:
>>>>> 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.
>>>> +1
>>> I do agree.
>>> NULL means "no data", not "0".In SQL "NULL = NULL" is false.
>>>
>>> Oracle chose empty string to be equivalent to NULL and it's quite a pain
>> to
>>> handle from a developper point of view.
>>>
>> Yeah, heard of that. And it would certainly be bad, if sqlpp11 did the
>> same. It does not.
>>
>> If you want to interpret NULL as NULL, fine, use the .is_null() method
>> to check.
>>
>> If you want to interpret NULL as "" or 0, also fine, just get the value.
>>
> I think all the DBMS provide a way to check that internally (NVL(column,
> default_value) for Oracle).
>
> What bother me is that you can have quite easily inconsistent behaviors.
> You retrieve values and you work with them in a select, you have no warning
> that a null value was encountered but you have no result or worse the wrong
> ones...
>
> It should not be the default behavior.
>
The behavior could be defined via the value_type as Bjorn suggested in
his post. But as soon as there is an outer join for instance, there
could be NULL values all over the place.

As stated in my reply to Edward, it is tough to impossible to determine
exactly which columns in a result set could be NULL, if the query
structure is not fully known at compile time. Would you want to turn
everything into a boost::optional then?

That would be pretty simple, of course.

Regards,

Roland