Re: [boost] SQL: next iteration of sqlpp11

Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2014-02-04 03:33:36

On Mon, Feb 3, 2014 at 10:25 PM, Johan Baltié <johan.baltie_at_[hidden]>wrote:

> On Mon, Feb 3, 2014 at 7:02 PM, Roland Bock <rbock_at_[hidden]> wrote:
> > On 2014-02-03 18:36, Johan Baltié wrote:
> > 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?
> >
>
> Yes. It seems the safer way to me.
>
> If an user doesn't like optionals he can add something to the statement so
> that he gets non optional types and an exception if a NULL occurs. I do not
> know if it is a good design idea, but throwing an exception when you've
> asserted that you do not wan't NULL does not seems stupid.
>

That's how Oracle OCI behaves. If you don't provide an explicit "indicator"
to know whether a value is null or not, OCI errors out if you do get a null
(and I convert this error into an exception myself).

So even w/o knowing the query at compile time, it's the client code that
decides whether nulls are OK by using (defining in OCI terms) an
optional<T> or a T (or another mechanism, I'm not tied to optional<>).

In contrast, SQLite just returns you an "abstract" value (
http://www.sqlite.org/c3ref/value.html) and has APIs to know the value's
type (http://www.sqlite.org/c3ref/value_blob.html), with null being of of
those "types". (and you can have values of the "wrong" type compared to the
declared type of the column, that's the dynamic nature of SQLite, unlike
most SQL engine).

IMHO, you cannot just assume in the general case an empty string, or a 0,
or a NaN, etc... are nulls. Nullness must be explicit, and not in the
value-space of the data you are binding (in WHERE clause or
inserting/updating) or defining (in SELECT clause).

My $0.02. --DD