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