Just FYI, things are really starting to shake up in the MySQL++
Subversion tree. Each revision is still usable, but there have been a
lot of API and ABI breakages recently. If any of you were thinking of
helping out with the testing for v2.0, now's a good time to start
building your programs against it, to give us early feedback on the
changes so far.

More changes are on the way, so if you were thinking of making just one
pass at this before release, hold off for a while yet. I'll post
another announcement like this once we think the API has settled down.

Go to http://gna.org/projects/mysqlpp/ to find out how to get a copy of
the current version in Subversion. Then read the HACKERS file to learn
how to "bootstrap" your tree, to get it to build.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

So far, I've hit only one regression-miss in my code, and I can't seem
to get to the cause of it. Hope someone knows.

I did a query for a non-existant something with a select, and
conceptually it contains a but (should check for error before getting a
row):

Query q = d_connection.query();
q << "select id from table where something";
ResUse result = q.use();

Row row = result.fetch_row();

if (result.eof())
throw NoResultError(.....);

However, with 2.0.0 (svn: 772) there is no way to find out that the
query didn't return any results. I would assume that either one
should be true after the q.use():


q.success() == false

result.eof() == true

result.operator bool() == false

Neither of the above is true. Am I missing something?

Also, my compiler was giving warnings about a non-virtual destructor in
lieu of virtual functions inherited from Lockable. Since the virtuals in
Lockable do seem ok to me, I applied the following totally trivial
patch:

Index: lib/connection.h
================================================== =================
--- lib/connection.h (revision 772)
+++ lib/connection.h (working copy)
@@ -105,7 +105,7 @@
unsigned int client_flag = 0);

/// \brief Destroy connection object
- ~Connection();
+ virtual ~Connection();

/// \brief Connect to database after object is created.
///

--
Erwin
erwin (AT) leastwanted (DOT) nl

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Erwin wrote:

That's not the right way to test for an empty result set. In fact,
eof() wraps a long-deprecated MySQL C API function, so I've removed it
from MySQL++. See the new simple2 example for the proper way to process
a "use" query. As shipped, it does the same thing as simple1, but if
you change the "select" statement to something that won't return
results, it does detect this case properly.

I think the proper change is to give Lockable a virtual dtor. I've done
this; update your tree and see if the new library compiles without warnings.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Warren Young wrote:
That example demonstrates good style for the "no exceptions" case, but
the situation wasn't so good for the "with exceptions" case. In the
earlier v2.0 code, you'd get a BadQuery exception when you hit the end
of the result set. Since the query is not in fact bad, I've created a
new EndOfResults exception to signal "fetch_row() walked off the end of
the result set". I've also added a new example, usequery.cpp, which
demonstrates it.

I considered returning v2.0 to v1.7-like behavior here, and simply
returning an empty row at the end of the result set. I rejected it
because the promise always has been that objects pass their exception
state on to their children. It didn't happen in v1.7, but this is a
bug, not a feature worth keeping. If you want the v1.7 behavior, use
the new NoExceptions facility on the ResUse object before you start
walking through the result set, but after you assign the return value of
Query::use() to it.

Along these lines, I'm going to create more new exceptions. BadQuery is
severely overloaded; it's pretty much a generic exception at this point.
I'm going to make it for bad queries only in v2.0. To avoid problems
when migrating between v1.7 and v2.0, all of your MySQL++ exception
catch blocks should include one for std::exception, which will act as a
"catch all" for those not caught by a more specific catch block. Most
of the examples have a block like this in v1.7, so if you've emulated
them, you won't need to change anything.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw