Author: wyoung
Date: Tue Jun 26 02:54:58 2007
New Revision: 1605

URL: http://svn.gna.org/viewcvs/mysqlpp?rev=1605&view=rev
Log:
Small tweaks to new SSQLS+BLOB section

Modified:
    trunk/doc/userman/userman.dbx

Modified: trunk/doc/userman/userman.dbx
URL: 
http://svn.gna.org/viewcvs/mysqlpp/trunk/doc/userman/userman.dbx?rev=1605&r1=1604&r2=1605&view=diff
==============================================================================
--- trunk/doc/userman/userman.dbx (original)
+++ trunk/doc/userman/userman.dbx Tue Jun 26 02:54:58 2007
@@ -1624,22 +1624,23 @@
         <para>BLOB columns are truncated when they contain null
         characters if you store them in an SSQLS. This happens because
         to get from the raw data format returned by the MySQL database
-        to an SSQLS field, the data goes through a conversion step
-        via <typename>ColData</typename>. The most correct target type
-        for a BLOB column is <typename>mysqlpp::sql_blob</typename>,
-        which is an alias for <typename>std::string</typename> at
-        the moment.  <typename>ColData</typename> converts to that
-        via <methodname>ColData::operator cchar*()</methodname>,
+        to an SSQLS field, the data goes through a conversion step via
+        <ulink type="classref" url="ColData__Tmpl">ColData</ulink>. The
+        most correct target type for a BLOB column is
+        <classname>mysqlpp::sql_blob</classname>, which is
+        currently an alias for <classname>std::string</classname>.
+        <classname>ColData</classname> converts to that via
+        <methodname>ColData::operator cchar*()</methodname>,
         which means the data is treated as a C string, so embedded
         nulls are treated as end-of-data markers. We can't just
         add an <methodname>operator std::string</methodname> to
-        <typename>ColData</typename>, because that creates a bunch
+        <classname>ColData</classname>, because that creates a bunch
         of type conversion ambiguities.</para>
 
         <para>I'm documenting this here because I don't
         see any easy fixes. The fix might require redesigning
-        <typename>ColData</typename>, which would have to wait until
-        v3.0. Alternately, we might have to create a dedicated BLOB
+        <classname>ColData</classname>, which would have to wait until
+        v3.0. Alternately, we could possibly create a dedicated BLOB
         data type, to make the correct conversion unambiguous to
         the compiler.</para>
 


_______________________________________________
Mysqlpp-commits mailing list
[email protected]
https://mail.gna.org/listinfo/mysqlpp-commits

Reply via email to