-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Wakely
I haven't looked at all the code yet, but I like the interface and what I've seen so far - I'm definitely interested in this library,
Thanks!
2) Boost.Database.Postgresql - an implementation of the above
interface
for postgresql
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.
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?
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.