From: Warren Young Date: November 18 2007 7:42am Subject: Re: Patch: Nullable fields in SQLSS List-Archive: http://lists.mysql.com/plusplus/7163 Message-Id: <473FECE9.4040905@etr-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David A. Betz wrote: > > I did not find mention in "8. Incompatible Library Changes" that the Query::success method had been obsoleted in favor of operator bool (). I don't change that chapter until shortly before making a public release, whether beta or final. Same for the ChangeLog. I do it this way because I synthesize a narrative for these documents from the svn log, to make them easier to understand. I need all the details in front of me to produce this higher-level picture. Unfortunately, the only place to get a list of what's changed at the moment is by reading through the raw svn commit log. Better to just fix 'em as you find 'em. > When using the patched version of mysql++, I was writing > > row["assigned_staff_nid"].get_null() > > Am I correct that with the svn version this becomes simply > > row["assigned_staff_nid"] > > and that this returns a mysqlpp::Null< Type, Behavior >::Null ? Kind of, yes. Row::operator[] doesn't return Null. What it does return is a mysqlpp::String. (The Class Formerly Known As ColData (TM)) That class has a bunch of implicit conversion operators on it, one of which is Null(), so this *should* work: Null my_val = row["some_column"]; Whether it actually does work or not depends on how happy that code makes the compiler, because C++ only allows one layer of conversion. If the compiler can't figure out how to get from mysqlpp::String to your desired data type with a single conversion, it will emit a veritable geyser of error messages in its state of discombobulation. Case studies and snippets testing this, both positive and negative, are welcome.