|
Boost : |
Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Roland Bock (rbock_at_[hidden])
Date: 2014-02-04 07:53:41
On 2014-02-04 10:40, Sebastian Theophil wrote:
>> On 2014-02-03 16:03, Roland Bock wrote:
>> 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...
> Hi Roland,
>
> while I can very well imagine that these "use-cases" exist, I would not like the library to make this the default. I think using boost::optional is the canonical solution that is also impossible to misinterpret.
As stated in other replies, please take a look here:
https://github.com/rbock/sqlpp11/wiki/NULL
I think this comes pretty close to what you and several others prefer,
without adding too much noise in my case.
>
> Treating non-existent values the same as default-initialized values seems error-prone if not wrong in general. The library should not prevent me from treating string "" differently from NULL, which currently it does.
Well, it does not /prevent/ you from differentiating between NULL and
"". It currently does not /force/ you to treat them differently. But as
stated above, I am willing to change that.
> On the other hand, if the library did return optionals, implementing the behaviour you describe on top of it is trivial:
>
> boost::optional<T> t;
> t.get_value_or( T() );
>
> If it helps my argument, both Scala Anorm and Scala Slick represent nullable columns as optional types:
>
> http://www.playframework.com/documentation/2.0/ScalaAnorm
> http://slick.typesafe.com/doc/2.0.0/schemas.html
Got that :-)
> Regards
> Sebastian
>
> PS: I hope to look at your library in more detail in the coming weeks and I am really looking forward to that. Great work so far.
Thanks! I am looking forward to your future comments, bug reports, etc.
Regards from Munich,
Roland
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk