Re: [boost] SQL: next iteration of sqlpp11

On Mon, Feb 3, 2014 at 10:25 PM, Johan Baltié wrote:

On Mon, Feb 3, 2014 at 7:02 PM, Roland Bock 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