On 2014-02-03 17:33, Edward Diener wrote:
On 2/3/2014 10:03 AM, Roland Bock wrote:
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...
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. I am fully aware that empty string and database NULL are completely different things. I am just saying that there are a bunch of use cases (several hundreds in the company I work for), where NULL can safely be interpreted as a trivial value and vice versa. I can explain such cases in more detail, if you want. They are not wrong :-)
Also, please note that there is the .is_null() method. sqlpp11 does not hide NULL from you (that would indeed be VERY wrong). That being said, I could of course add a conversion operator to boost::optional where applicable. That in itself would be extremely simple. It would take some time to get there, though, since sqlpp11 would have to be fully aware of when exactly a value could be null. An Outer Join for instance would turn everything into optionals. The data is available, the logic is not complete yet. Also, for dynamic queries (where the query's structure is not fully known at runtime), it might very well be impossible to determine whether something can be NULL or not. Should I turn all doubtful cases into boost::optional? That doesn't feel right. Regards, Roland