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 10:03:31

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...

This approach shows not only in result evaluation but also supported
during statement construction with the tvin() method (yet to be
documented): tvin stands for Trivial Value Is NULL, e.g:

select(all_of(tab)).from(tab).where(tab.beta == sqlpp::tvin(some_string));

The condition will be interpreted as

tab.beta = 'some string'

or

tab.beta IS NULL

depending on the value of the variable some_string.

Also, it seems to me that binding binary parameters and result fields to
boost::optional might be harder to do. But then, sqlpp11 is relatively
easy to extend when it comes to new functions or value types. If you
want types based on boost optional, you could have that (although you'd
probably have to deal with the binary binding in some cases). It might
be a nice extension :-)

Cheers,

Roland