Warren Young wrote:
> If that's appropriate code for your application, it implies SQL NULL
> has no special significance to you, so you should drop it from the DB.
Could you give me a brief example of a scenario where NULL would have
special significance? I was under the impression that Null<foo> should
be used wherever Null was set to "yes" in the database schema and,
therefore in theory at least, that field could potentially be null. In
other words a null is a possibility. You are correct that in this case a
null to me is just an empty string so NullIsBlank would be fine. I am
interested in understanding where this would be used though so if you
have a moment to explain it I would appreciate it, or if you could point
me to some relevant docs?
> If you can't change the DB, use the NullIsBlank behavior. If you do
> that, the code can be:
I could change the DB so that the filed can't be null and must just be
an empty string, I could also use NullIsBlank.
> something_that_requires_a_c_string = sql_char(it->mobileNumber).c_str();
> You need the explicit conversion in there because C++ won't implicitly
> do two casts in a row.
Understand, would I be better off using
> Actually, this might work, too:
> something_that_requires_a_c_string = sql_char(it->mobileNumber);
> ...because sql_char has a const char* operator.
> If SQL NULL does mean something different from blank in your
> application, then I question whether the quoted code above is even
> appropriate. Maybe different parts of your application have more
> stringent requirements than others, but you should think about which
> case applies, not just blindly cast away NULLness.
See above, I'm wrestling with this as I am not sure I grasp the concept
of "significant nulls" at the moment.