Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Roland Bock (rbock_at_[hidden])
Date: 2014-02-04 14:17:03
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
>>>> 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
>>>> to have to check if there really is a value, or always use
>>> 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.
>> 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.
>> 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
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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk