Re: [boost] SQL: next iteration of sqlpp11

Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Sebastian Theophil (stheophil_at_[hidden])
Date: 2014-02-04 04:40:28

> 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.

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. 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

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.
--
Dr. Sebastian Theophil | stheophil_at_[hidden]
Senior Software Engineer
think-cell Sales GmbH & Co. KG | Chausseestr. 8/E | 10115 Berlin | Germany
http://www.think-cell.com | phone [phone] | US phone [phone]
Amtsgericht Berlin-Charlottenburg, HRA 44531 | European Union VAT Id DE815233792
General partner: think-cell Operations GmbH | Amtsgericht Berlin-Charlottenburg HRB 129917
Directors: Dr. Markus Hannebauer, Dr. Arno Sch?dl