Brock Peabody wrote:
On Behalf Of Jonathan Wakely I have an implementation of your database library for MySQL. It's on my hard drive at home and I'm broadband-less right now so if anyone wants to see it let me know and I'll dial up tonight. It was very easy to adapt to use the MySQL API.
I'd like to see it when you get a chance.
Sure, I'll post it tonight or tomorrow.
postgresql/connect.cpp accidentally uses the <:: trigraph in the typedefs at the top of the file. You need a space before the template args to avoid that.
Maybe I should put the files in the sandbox? Did you happen to make Boost.Jam files to compile the test?
No, I'm fairly proficient with make and completely ignorant of bjam so I knocked up a Makefile that would let me test your impl and mine with either "make IMPL=postgresql" or "make IMPL=mysql" (and is easily extended to other impl's).
How do you handle NULL values? the postgresql::row_set_imp::get() function doesn't seem to account for NULL, which would crash strlen(), atof() etc.
I was thinking about this some more. Long ago, where I work we had bad experiences with once working programs crashing when they tried to read null fields (via DAO) when we really just wanted default values (0s and empty strings). Ever since then when I've written a wrapper for a database library I've always provided automatic conversion of nulls to default values.
Now that you've brought this up, however, I can see that not only are nulls important to some users, but that they will also be important for the serialization library when serializing boost::optionals. The method I'm using now is not so good.
Yes, it's essential to distinguish NULL in some situations (particularly if you've got left joins in the query) jon -- "Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them." - Joseph Heller