Re: [boost] SQL: next iteration of sqlpp11

Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Johan Baltié (johan.baltie_at_[hidden])
Date: 2014-02-03 12:36:20

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.

--
Cheers
Johan