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