On 2014-02-04 19:56, Edward Diener wrote:
On 2/4/2014 2:05 AM, Roland Bock wrote:
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.
Edward,
after a short night's sleep I drafted a document for how sqlpp11 could cover both use cases:
1. NULL is NULL and nothing else, dammit! 2. NULL or 0? Sometimes I just don't care.
https://github.com/rbock/sqlpp11/wiki/NULL
Please let me know what you think.
This is strictly my preference but I think it would be much easier and cleaner if all values, as objects, passed to and returned from a database were boost::optional<T> values for the particular type T of a column. That way the possibility that a column could hold a DB NULL value would be fully taken care of and it is now up to the end-user to realize that a DB NULL could be a valid value and deal with it accordingly.
I admit that the idea of using boost::optional (or something very similar) not only for select results but also for values in statements is growing on me. It seems like a nice symmetry indeed. I'll spend some time letting it sink (and I also need to think about how to handle my own use case elegantly). Thanks and regards, Roland