From: Raymond Boettcher
Date: April 5 2011 4:23am
Subject: Re: Mysql++ AVOID NULL Columns!! :)
List-Archive: http://lists.mysql.com/plusplus/9312
Message-Id: <912811.99048.qm@web38004.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1409520767-1301977410=:99048"

--0-1409520767-1301977410=:99048
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

 >> If it's an STL container of SSQLSes instead, the only reason you might =
have had to do that is that your SSQLS wasn't defined using mysqlpp::Null<T=
> wrappers on the columns that can contain SQL NULL. That wasn't possible p=
re-MySQL++ 3.0, but it is now, so any reason you had for doing that once ha=
s gone away.

That is good to know.=A0 I know that mysql++ has definitely had come code c=
hanges.=A0 Every once in a while I find myself fixing some function in my p=
rogram because I'm using the "old" call to do things.

>> Getting back to Eric's issue, you are correct, Raymond, that comparing t=
o the C NULL constant is wrong, and that part of the fix is to compare agai=
nst MySQL++'s mysqlpp::null value.

I figured that was right.=A0 I remember using it somewhere in my code at on=
e time before I killed the use of NULL completely.=A0 That was part of my c=
omparing sqltypes to sqltypes learning curve back in the day.=A0 Most of my=
 conversions for strings, etc are done via ostringstream variable; variable=
 << Result[x][y];...=A0 From that placepoint I could use it how I wish.=A0 =
Then I simply create the execute statement using the ostringstream variable=
 which can be converted to string and then ultimately to char (where needed=
).=A0 It's a painful process and but it allows me to include any variable t=
ype in the execution line since using << dumps the contents of the variable=
 into ostringstream regardless of the type.=A0 This practice solves so many=
 issues and prevents having to cast everything into a string for execution =
which generally leads to cast problems in the end anyhow.

I'm pretty sure I'm over-doing it these days, but it's how I learned to use=
 mysql++ back when it was in it's infancy.=A0 I never really updated my sty=
le since I've only looked up things related to mysql++ when I end in a comp=
ile error for some member that is no longer found in the new release of mys=
ql++.=A0 In some of my examples I just simply install the old version simpl=
y because the program is so big that making all the member conversions and =
ensuring the program produces the same results can be painful in itself.

>>> I even use
>>> mysqlpp::sql_int_unsigned, etc for some of my variables

>>Are you using mysqlpp::sql_int_unsigned_null, etc., too?=A0 That's shorth=
and for mysqlpp::Null<sql_int_unsigned>, etc.

No, actually after the big issues with null long ago, I have completely eli=
minated NULL from the equation of my programs with the "NOT NULL" column pr=
operty.=A0 After that, I never looked back at it until this e-mail showed u=
p.=A0 As I stated before, I have zero reason to ever use NULL...=A0 I can't=
 think of one example that NULL would be better than a zero byte string.

I think NULL should be able to be disabled via a flag during the init of th=
e mysql++ library using a parm on the connect command.=A0 In that instance =
string should be converted to "" and int to 0, etc...=A0 Basically the clie=
nts version of the "NOT NULL" column property.=A0 But since I haven't found=
 an option like that, I just handle it from the SQL Server side.=A0 It's mo=
re suited for it anyway, you can set a default value for the column which i=
s something I'd never expect the client to keep track of.

Although it would be nice if the client looked up that information so I don=
't have to execute the insert command and then relook it up using "SELECT" =
to actually get the default values back (for instances where you are using =
struct to create inserts instead of manual commands).=A0 Which isn't someth=
ing I have to do that often but I've had instances where I wanted to store =
the record number (index) from the table and since I don't set that on INSE=
RT and it's the primary key for the table, it creates it automatically.=A0 =
The only way to get that key is to SELECT after the INSERT (Good for those =
inserts where the key is something useful that needs to be reported back to=
 the user.=A0 IE:=A0 Maybe it's the Service Ticket #, etc which explains wh=
y it needs to be unique).=A0 You could sort by Key and use the next key in =
line but in a networking environment where more than one user is INSERTing =
a Service Ticket there is the possibility of having a failure because two
 clients tried to insert the same ticket number at the same time (one will =
likely succeed and one will fail).=A0 For that instance alone it's better t=
o let MySQL Server keep track of the Key Column by incrementing it on it's =
own accord.

Raymond Boettcher

--0-1409520767-1301977410=:99048--