diff --git a/COPYING.txt b/COPYING.txt index a52a46b..e7ea628 100644 --- a/COPYING.txt +++ b/COPYING.txt @@ -1,10 +1,10 @@ -The MySQL++ library proper and the reference manual derived from -comments in the library source code are licensed under the GNU Lesser -General Public License. A copy is provided in this directory, in the -file LICENSE.txt. - -The MySQL++ User Manual is licensed under a unique license derived from -the Linux Documentation Project License. (The only changes are due to -the fact that the User Manual isn't actually part of the LDP, so a lot -of the language in the LDPL doesn't make sense when applied to the user -manual.) This license is provided in the file doc/userman/LICENSE.txt. +The MySQL++ library proper and the reference manual derived from +comments in the library source code are licensed under the GNU Lesser +General Public License. A copy is provided in this directory, in the +file LICENSE.txt. + +The MySQL++ User Manual is licensed under a unique license derived from +the Linux Documentation Project License. (The only changes are due to +the fact that the User Manual isn't actually part of the LDP, so a lot +of the language in the LDPL doesn't make sense when applied to the user +manual.) This license is provided in the file doc/userman/LICENSE.txt. diff --git a/CREDITS.txt b/CREDITS.txt index 393a989..12888ff 100644 --- a/CREDITS.txt +++ b/CREDITS.txt @@ -1,93 +1,93 @@ -MySQL++ was created by Kevin Atkinson during 1998. From version 1.0 -(released in June 1999) through 1.7.9 (May 2001), the primary maintainer -was Sinisa Milivojevic . Neither Kevin nor Sinisa -are currently involved in MySQL++ development. The current maintainer -is Warren Young , starting with version 1.7.10 in -August of 2004. - -For a fuller account of the library's history, see the first chapter -of the user manual. For the nitty-gritty details, see the ChangeLog -in the root package directory. ChangeLog items since 1.7.9 that -aren't attributed to anyone else were done by Warren Young. - - -Other contributors of note since 1.7.10: - - Chris Frey : Lots of GCC warning fixes for the - bleeding-edge compiler versions, and Gentoo ebuild support. - - Mark Meredino : Several fixes and - additions, including a lot of work on Microsoft Visual C++ - compatibility, and discoveries made while spelunking in the - library. - - Evan Wies : Contributed several C++ code - style cleanups. - - Arnon Jalon : Added the multi-query - result set handling features, and examples/multiquery.cpp to - demonstrate it. - - Korolyov Ilya has submitted several patches in many different - areas of the library. - - Remi Collet is maintaining offical RPMs - for Fedora, with other systems on the way. His work has improved - the RPM spec file we distribute greatly. - - Joel Fielder came up with the - original idea for Query::for_each() and Query::store_in(), - provided the basis for examples/for_each.cpp, and provided a fix - for exception flag propagation in Query. - - Jim Wallace demonstrated the need - for BadQuery::errnum(), and contributed the patches and also - examples/deadlock.cpp to test that this feature does what it is - supposed to. - - Jonathan Wakely rebuilt my original versions - of ConnectionPool, RefCountedPointer, and RefCountedBuffer. - They're now simpler and safer. He also created the numeric - conversion logic in lib/mystring.h introduced in v3.0. - - -Here are the personal credits from the old 1.7.9 documentation, -apparently written by Kevin Atkinson: - - Chris Halverson - For helping me get it to compile under Solaris. - - Fredric Fredricson - For a long talk about automatic conversions. - - Michael Widenius - MySQL developer who has been very supportive of - my efforts. - - Paul J. Lucas - For the original idea of treating the query object - like a stream. - - Scott Barron - For helping me with the shared libraries. - - Jools Enticknap - For giving me the Template Queries idea. - - M. S. Sriram - For a detailed dission of how the Template Queries - should be implemented, the suggestion to throw exceptions on bad - queries, and the idea of having a back-end independent query - object (ie SQLQuery). - - Sinisa Milivojevic - For becoming the new offical maintainer. - - D. Hawkins and E. Loic for their autoconf + automake contribution. - - -See the ChangeLog for further credits, and details about the differences -between the many versions of this library. - - -Please do not email any of these people with general questions about -MySQL++. All of us who are still active in MySQL++ development read the -mailing list, so questions sent there do get to us: - - http://lists.mysql.com/plusplus - -The mailing list is superior to private email because the answers are -archived for future questioners to find, and because you are likely to -get answers from more people. +MySQL++ was created by Kevin Atkinson during 1998. From version 1.0 +(released in June 1999) through 1.7.9 (May 2001), the primary maintainer +was Sinisa Milivojevic . Neither Kevin nor Sinisa +are currently involved in MySQL++ development. The current maintainer +is Warren Young , starting with version 1.7.10 in +August of 2004. + +For a fuller account of the library's history, see the first chapter +of the user manual. For the nitty-gritty details, see the ChangeLog +in the root package directory. ChangeLog items since 1.7.9 that +aren't attributed to anyone else were done by Warren Young. + + +Other contributors of note since 1.7.10: + + Chris Frey : Lots of GCC warning fixes for the + bleeding-edge compiler versions, and Gentoo ebuild support. + + Mark Meredino : Several fixes and + additions, including a lot of work on Microsoft Visual C++ + compatibility, and discoveries made while spelunking in the + library. + + Evan Wies : Contributed several C++ code + style cleanups. + + Arnon Jalon : Added the multi-query + result set handling features, and examples/multiquery.cpp to + demonstrate it. + + Korolyov Ilya has submitted several patches in many different + areas of the library. + + Remi Collet is maintaining offical RPMs + for Fedora, with other systems on the way. His work has improved + the RPM spec file we distribute greatly. + + Joel Fielder came up with the + original idea for Query::for_each() and Query::store_in(), + provided the basis for examples/for_each.cpp, and provided a fix + for exception flag propagation in Query. + + Jim Wallace demonstrated the need + for BadQuery::errnum(), and contributed the patches and also + examples/deadlock.cpp to test that this feature does what it is + supposed to. + + Jonathan Wakely rebuilt my original versions + of ConnectionPool, RefCountedPointer, and RefCountedBuffer. + They're now simpler and safer. He also created the numeric + conversion logic in lib/mystring.h introduced in v3.0. + + +Here are the personal credits from the old 1.7.9 documentation, +apparently written by Kevin Atkinson: + + Chris Halverson - For helping me get it to compile under Solaris. + + Fredric Fredricson - For a long talk about automatic conversions. + + Michael Widenius - MySQL developer who has been very supportive of + my efforts. + + Paul J. Lucas - For the original idea of treating the query object + like a stream. + + Scott Barron - For helping me with the shared libraries. + + Jools Enticknap - For giving me the Template Queries idea. + + M. S. Sriram - For a detailed dission of how the Template Queries + should be implemented, the suggestion to throw exceptions on bad + queries, and the idea of having a back-end independent query + object (ie SQLQuery). + + Sinisa Milivojevic - For becoming the new offical maintainer. + + D. Hawkins and E. Loic for their autoconf + automake contribution. + + +See the ChangeLog for further credits, and details about the differences +between the many versions of this library. + + +Please do not email any of these people with general questions about +MySQL++. All of us who are still active in MySQL++ development read the +mailing list, so questions sent there do get to us: + + http://lists.mysql.com/plusplus + +The mailing list is superior to private email because the answers are +archived for future questioners to find, and because you are likely to +get answers from more people. diff --git a/ChangeLog b/ChangeLog index 490100e..36d0cda 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,19 @@ +3.0.3, 2008.05.11 (r2284) + + o Fixed query well-formedness handling in Query::store() and use(). + It was quietly eating these errors, confusing them with the + no-results case. + + o Fixed examples/cpool.cpp to build without thread support. + + o No longer hiding all stdint.h typedefs inside namespace mysqlpp. + + o Fixed mysqlpp::String comparisons of empty strings against + nonempty strings; if the empty string was on the left hand side, + it would succeed because it was only comparing against characters + in the empty side, which matches everything. (Fixes bug 11588.) + + 3.0.2, 2008.04.13 (r2275) o Increased float to string conversion precision from 7 to 9 and @@ -7,7 +23,7 @@ o Replaced Query's safe bool mechanism with an override of basic_ios::operator void*() to avoid a conflict between the two mechanisms. As the base class version isn't virtual, - this is arguably evil, but it should be harmess in typical use. + this is arguably evil, but it should be harmless in typical use. Besides, testing Query in bool context usually isn't the right thing anyway: test the result set instead. diff --git a/HACKERS.txt b/HACKERS.txt index 4b026ff..0d54e39 100644 --- a/HACKERS.txt +++ b/HACKERS.txt @@ -1,228 +1,228 @@ -If you are going to make any changes to MySQL++, this file has some -hints and commentary you may find helpful. - - -Subversion Access -~~~~~~~~~~~~~~~~~ - To check out the current development version from the Gna! - Subversion repository, say: - - $ svn co svn://svn.gna.org/svn/mysqlpp/trunk mysqlpp - - If you're a MySQL++ committer, use svn over ssh instead: - - $ svn co svn+ssh://LOGIN@svn.gna.org/svn/mysqlpp/trunk mysqlpp - - where LOGIN is your Gna! login name. You will have to have your - ssh public key(s) registered with Gna! for this to work. - - -Bootstrapping the Library -~~~~~~~~~~~~~~~~~~~~~~~~~ - When you check out MySQL++ from svn, there are a lot of things - "missing" as compared to a distributed tarball, because the - svn repository contains only source files, no generated files. - - If you're using Windows, there is a simple batch file called - bootstrap.bat which wraps up all the steps you need to build - these "missing" files. To run it, just say "bootstrap" from a - command shell in the top MySQL++ source directory. For it to run - correctly, you will need Bakefile 0.2.3 (http://bakefile.org/) and - a Perl 5 interpreter installed on your system, both in the PATH. - The bootstrap script is smart enough to recognize when these - tools are missing and stop processing so you can fix the problem. - - For all other platforms, there's a Bourne shell script called - bootstrap. It's quite a bit more complex than the bootstrap.bat - file. It does more, and takes many optional arguments to control - its behavior. All of this is documented in a separate section - below. For many systems, it suffices to just run it without - any arguments: - - $ ./bootstrap - - In addition to Bakefile 0.2.3 and Perl 5, you'll also need autoconf - 1.59 or higher for this to run successfully. - - -Submitting Patches -~~~~~~~~~~~~~~~~~~ - If you wish to submit a patch to the library, please send it to - the MySQL++ mailing list, or attach it to an entry in our bug - tracker on Gna! We want patches in unified diff format. - - The easiest way to get a unified diff is to check out a copy of - the current MySQL++ tree as described in the previous section. - Then make your change, cd to the MySQL++ root directory, and ask - Subversion to generate the diff for you: - - $ svn diff > mychange.patch - - If your patch adds new files to the distribution, you can say - "svn add newfile" before you do the diff, which will include - the contents of that file in the patch. (You can do this even - when you've checked out the tree anonymously.) Then say "svn - revert newfile" to make Subversion forget about the new file. - - If you're making a patch against a MySQL++ distribution tarball, - then you can generate the diff this way: - - $ diff -ruN mysql++-olddir mysql++-newdir > mychange.patch - - The diff command is part of every Unix and Linux system, and - should be installed by default. If you're on a Windows machine, - GNU diff is part of Cygwin (http://cygwin.com/). Subversion is - also available for all of these systems. There are no excuses - for not being able to make unified diffs. :) - - -Testing Your Proposed Change -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - In v2.3.2, we added a new script called 'dtest'. You run it - like you would most of the examples, except that you don't need - to run it via exrun: - - $ ./dtest [password] [user] [server_addr] - - This automatically runs most of the examples, captures the outputs - to a file, and then compares that to a known-good run's outputs. - The purpose of this is that, before you submit a patch, run dtest - and see if it indicates that anything has changed. If something - has and you can't account for it, it represents a problem that - you'll have to fix before submitting the patch. - - If your change purposely causes different outputs from the dtest - run stored in svn, remove the bmark.txt file, then re-run dtest and - include the bmark.txt diffs with your patch. This communicates - to us the fact that you know there are differences and want the - patch evaluated anyway. Otherwise, we are likely to view the - change as a bug. - - -Adding Support for a Different Compiler -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - MySQL++ uses the Bakefile system for creating project files - and makefiles. This allows us to make changes to a single set - of files, and have the proper changes be made to all generated - project files and makefiles. In the past, we used more ad-hoc - systems, and we'd frequently forget to update individual project - files and makefiles, so at any given time, at least one target - was likely to be broken. - - If MySQL++ doesn't currently ship with project files or makefiles - tuned for your compiler of choice, you need to work through the - Bakefile mechanism to add support. We're not willing to do ad-hoc - platform support any more, so please don't ask if you can send - us project files instead; we don't want them. - - If you want to port MySQL++ to another platform, we need to be - confident that the entire library works on your platform before - we'll accept patches. In the past, we've had broken ports that - were missing important library features, or that crashed when built - in certain ways. Few people will knowingly use a crippled version - of MySQL++, since there are usually acceptable alternatives. - Therefore, such ports become maintenance baggage with little - compensating value. - - -On Manipulating the Build System Source Files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If you're using Visual C++, there are two ways to change the Visual - Studio project files: - - - You can just make the changes directly within Visual Studio. This - is a fine way to do it if you're only making small changes for - your own purposes. - - - The Visual Studio project files are actually generated from - mysql++.bkl by a tool called Bakefile, not maintained directly. - (We do it this way because Bakefile can generate many different - types of makefiles and project files from this single source file, - so all the platforms we support get all the changes at once.) So, - if you want to make changes to the project files and contribute - them back to the MySQL++ project, you need to do the changes - in mysql++.bkl instead. Rather than run Bakefile directly to - regenerate the project files, we've wrapped up the necessary steps - in the rebake.bat batch file. Any arguments passed to rebake get - sent on to Bakefile without change. - - If you're on a Unixy platform, things are a little more complex - because the build system uses Autoconf in addition to Bakefile. - The source files are mysql++.bkl, configure.ac, and config/*. If you - change any of these, run the bootstrap script to rebuild all their - descendant files. - - The bootstrap script also has other functions besides running - Bakefile and Autoconf for you: - - $ ./bootstrap [no{doc,ex,lib,opt}] [pedantic] [bat] \ - [configure flags] - - Arguments: - - nodoc The documentation won't be considered a prerequisite for - building the distribution tarball. This is useful on systems - where the documentation doesn't build correctly, and you only - need to make a binary RPM. That process requires a tarball, - but doesn't need the documentation. Don't distribute the - tarball or SRPM that results, as they are no good for any - other purpose. - - noex The generated Makefiles and project files won't try to build - any of the examples. - - nolib The generated Makefiles and project files won't try to build - the MySQL++ library. - - nomaint Turn off "maintainer mode" stuff in the build. These are - features used only by those building MySQL++ from svn. The - 'dist' build target uses this when creating the tarball. - - noopt Compiler optimization will be turned off. (This currently - has no effect on MinGW or Visual C++.) - - pedantic - Turns on all of GCC's warnings and portability checks. - Good for checking changes before making a public release. - - bat Asks cmd.exe to run bootstrap.bat for you. This is useful - when using Cygwin just as a command shell in preference - to cmd.exe, as opposed to using Cygwin to build MySQL++ - using its native tools. Passing 'bat' stops all command - line processing in the bootstrap script, so if you - also pass some of the other options, make 'bat' last. - The only options that affect the built project files and - Makefiles work are the no* ones. - - configure options - As soon as the bootstrap script sees an option that it - doesn't understand, it stops processing the command line. - Any subsequent options are passed to the configure script. - See README-Unix.txt for more on configure script options. - - -Maintaining a Private CVS Repository -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - You may find it helpful to maintain your own CVS repository. - Whenever there is a new MySQL++ release, import it on the vendor - branch like this: - - $ cvs import -m "Version 1.7.35" software/mysql++ mysql++ mysql++-1_7_35 - - (This assumes that you have your CVSROOT environment variable - set properly.) - - Update the HEAD branch like this: - - $ cd mysql++ - $ cvs update -PdA - $ cvs update -j HEAD -j mysql++-1_7_35 -Pd - $ cvs ci -m "merged 1.7.35 into HEAD" - $ cvs tag mysql++-1_7_35-merged - - Then any changes you make can easily be tracked, and diffs can - be produced with rdiff: - - $ cvs rdiff -ru mysql++-1_7_35 -r mysql++-1_7_35_equal_list \ - $(cat CVS/Repository) > equal_list.patch - +If you are going to make any changes to MySQL++, this file has some +hints and commentary you may find helpful. + + +Subversion Access +~~~~~~~~~~~~~~~~~ + To check out the current development version from the Gna! + Subversion repository, say: + + $ svn co svn://svn.gna.org/svn/mysqlpp/trunk mysqlpp + + If you're a MySQL++ committer, use svn over ssh instead: + + $ svn co svn+ssh://LOGIN@svn.gna.org/svn/mysqlpp/trunk mysqlpp + + where LOGIN is your Gna! login name. You will have to have your + ssh public key(s) registered with Gna! for this to work. + + +Bootstrapping the Library +~~~~~~~~~~~~~~~~~~~~~~~~~ + When you check out MySQL++ from svn, there are a lot of things + "missing" as compared to a distributed tarball, because the + svn repository contains only source files, no generated files. + + If you're using Windows, there is a simple batch file called + bootstrap.bat which wraps up all the steps you need to build + these "missing" files. To run it, just say "bootstrap" from a + command shell in the top MySQL++ source directory. For it to run + correctly, you will need Bakefile 0.2.3 (http://bakefile.org/) and + a Perl 5 interpreter installed on your system, both in the PATH. + The bootstrap script is smart enough to recognize when these + tools are missing and stop processing so you can fix the problem. + + For all other platforms, there's a Bourne shell script called + bootstrap. It's quite a bit more complex than the bootstrap.bat + file. It does more, and takes many optional arguments to control + its behavior. All of this is documented in a separate section + below. For many systems, it suffices to just run it without + any arguments: + + $ ./bootstrap + + In addition to Bakefile 0.2.3 and Perl 5, you'll also need autoconf + 1.59 or higher for this to run successfully. + + +Submitting Patches +~~~~~~~~~~~~~~~~~~ + If you wish to submit a patch to the library, please send it to + the MySQL++ mailing list, or attach it to an entry in our bug + tracker on Gna! We want patches in unified diff format. + + The easiest way to get a unified diff is to check out a copy of + the current MySQL++ tree as described in the previous section. + Then make your change, cd to the MySQL++ root directory, and ask + Subversion to generate the diff for you: + + $ svn diff > mychange.patch + + If your patch adds new files to the distribution, you can say + "svn add newfile" before you do the diff, which will include + the contents of that file in the patch. (You can do this even + when you've checked out the tree anonymously.) Then say "svn + revert newfile" to make Subversion forget about the new file. + + If you're making a patch against a MySQL++ distribution tarball, + then you can generate the diff this way: + + $ diff -ruN mysql++-olddir mysql++-newdir > mychange.patch + + The diff command is part of every Unix and Linux system, and + should be installed by default. If you're on a Windows machine, + GNU diff is part of Cygwin (http://cygwin.com/). Subversion is + also available for all of these systems. There are no excuses + for not being able to make unified diffs. :) + + +Testing Your Proposed Change +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + In v2.3.2, we added a new script called 'dtest'. You run it + like you would most of the examples, except that you don't need + to run it via exrun: + + $ ./dtest [password] [user] [server_addr] + + This automatically runs most of the examples, captures the outputs + to a file, and then compares that to a known-good run's outputs. + The purpose of this is that, before you submit a patch, run dtest + and see if it indicates that anything has changed. If something + has and you can't account for it, it represents a problem that + you'll have to fix before submitting the patch. + + If your change purposely causes different outputs from the dtest + run stored in svn, remove the bmark.txt file, then re-run dtest and + include the bmark.txt diffs with your patch. This communicates + to us the fact that you know there are differences and want the + patch evaluated anyway. Otherwise, we are likely to view the + change as a bug. + + +Adding Support for a Different Compiler +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + MySQL++ uses the Bakefile system for creating project files + and makefiles. This allows us to make changes to a single set + of files, and have the proper changes be made to all generated + project files and makefiles. In the past, we used more ad-hoc + systems, and we'd frequently forget to update individual project + files and makefiles, so at any given time, at least one target + was likely to be broken. + + If MySQL++ doesn't currently ship with project files or makefiles + tuned for your compiler of choice, you need to work through the + Bakefile mechanism to add support. We're not willing to do ad-hoc + platform support any more, so please don't ask if you can send + us project files instead; we don't want them. + + If you want to port MySQL++ to another platform, we need to be + confident that the entire library works on your platform before + we'll accept patches. In the past, we've had broken ports that + were missing important library features, or that crashed when built + in certain ways. Few people will knowingly use a crippled version + of MySQL++, since there are usually acceptable alternatives. + Therefore, such ports become maintenance baggage with little + compensating value. + + +On Manipulating the Build System Source Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + If you're using Visual C++, there are two ways to change the Visual + Studio project files: + + - You can just make the changes directly within Visual Studio. This + is a fine way to do it if you're only making small changes for + your own purposes. + + - The Visual Studio project files are actually generated from + mysql++.bkl by a tool called Bakefile, not maintained directly. + (We do it this way because Bakefile can generate many different + types of makefiles and project files from this single source file, + so all the platforms we support get all the changes at once.) So, + if you want to make changes to the project files and contribute + them back to the MySQL++ project, you need to do the changes + in mysql++.bkl instead. Rather than run Bakefile directly to + regenerate the project files, we've wrapped up the necessary steps + in the rebake.bat batch file. Any arguments passed to rebake get + sent on to Bakefile without change. + + If you're on a Unixy platform, things are a little more complex + because the build system uses Autoconf in addition to Bakefile. + The source files are mysql++.bkl, configure.ac, and config/*. If you + change any of these, run the bootstrap script to rebuild all their + descendant files. + + The bootstrap script also has other functions besides running + Bakefile and Autoconf for you: + + $ ./bootstrap [no{doc,ex,lib,opt}] [pedantic] [bat] \ + [configure flags] + + Arguments: + + nodoc The documentation won't be considered a prerequisite for + building the distribution tarball. This is useful on systems + where the documentation doesn't build correctly, and you only + need to make a binary RPM. That process requires a tarball, + but doesn't need the documentation. Don't distribute the + tarball or SRPM that results, as they are no good for any + other purpose. + + noex The generated Makefiles and project files won't try to build + any of the examples. + + nolib The generated Makefiles and project files won't try to build + the MySQL++ library. + + nomaint Turn off "maintainer mode" stuff in the build. These are + features used only by those building MySQL++ from svn. The + 'dist' build target uses this when creating the tarball. + + noopt Compiler optimization will be turned off. (This currently + has no effect on MinGW or Visual C++.) + + pedantic + Turns on all of GCC's warnings and portability checks. + Good for checking changes before making a public release. + + bat Asks cmd.exe to run bootstrap.bat for you. This is useful + when using Cygwin just as a command shell in preference + to cmd.exe, as opposed to using Cygwin to build MySQL++ + using its native tools. Passing 'bat' stops all command + line processing in the bootstrap script, so if you + also pass some of the other options, make 'bat' last. + The only options that affect the built project files and + Makefiles work are the no* ones. + + configure options + As soon as the bootstrap script sees an option that it + doesn't understand, it stops processing the command line. + Any subsequent options are passed to the configure script. + See README-Unix.txt for more on configure script options. + + +Maintaining a Private CVS Repository +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + You may find it helpful to maintain your own CVS repository. + Whenever there is a new MySQL++ release, import it on the vendor + branch like this: + + $ cvs import -m "Version 1.7.35" software/mysql++ mysql++ mysql++-1_7_35 + + (This assumes that you have your CVSROOT environment variable + set properly.) + + Update the HEAD branch like this: + + $ cd mysql++ + $ cvs update -PdA + $ cvs update -j HEAD -j mysql++-1_7_35 -Pd + $ cvs ci -m "merged 1.7.35 into HEAD" + $ cvs tag mysql++-1_7_35-merged + + Then any changes you make can easily be tracked, and diffs can + be produced with rdiff: + + $ cvs rdiff -ru mysql++-1_7_35 -r mysql++-1_7_35_equal_list \ + $(cat CVS/Repository) > equal_list.patch + diff --git a/INSTALL.txt b/INSTALL.txt index 5dccaa7..c9c6711 100644 --- a/INSTALL.txt +++ b/INSTALL.txt @@ -1,9 +1,9 @@ -The installation procedure depends on the compiler you use to build -MySQL++. See: - - README-Cygwin.txt - for Cygwin - README-MinGW.txt - for MinGW - README-Unix.txt - for Unix, Linux, Mac OS X, etc. - README-Visual-C++.txt - for Visual C++ - -Also see the main README.txt file for things that apply to all systems. +The installation procedure depends on the compiler you use to build +MySQL++. See: + + README-Cygwin.txt - for Cygwin + README-MinGW.txt - for MinGW + README-Unix.txt - for Unix, Linux, Mac OS X, etc. + README-Visual-C++.txt - for Visual C++ + +Also see the main README.txt file for things that apply to all systems. diff --git a/README-Cygwin.txt b/README-Cygwin.txt index a4f494a..be3b134 100644 --- a/README-Cygwin.txt +++ b/README-Cygwin.txt @@ -1,34 +1,34 @@ -Prerequisite: Build MySQL -~~~~~~~~~~~~~~~~~~~~~~~~~ - Before you can build MySQL++, you need to build the MySQL client - library from source. This is necessary because Cygwin programs - work best when linked to Cygwin libraries, even though it's - possible to link to some native Windows libraries. You do not - need to build a Cygwin version of the MySQL server; it's still - best to use the native Windows version of that. - - The MySQL client library does not build correctly out of the box. - The best instructions I've found covering the necessary changes - are here: - - http://cygwin.com/ml/cygwin/2004-11/msg00159.html - - I recommend that you use MySQL v4.1.x at this time. Skip the - step changing the pthread stuff in my_thr_init.c, as this change - has already been made in recent versions of MySQL. - - With the changes applied, build and install the client library - like so: - - $ autoreconf --install --verbose --force - $ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ - --infodir=/usr/share/info --mandir=/usr/share/man \ - --disable-shared --without-{debug,readline,libedit,server} - $ make - $ make install - - -Building the Library and Example Programs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - With that done, you can build MySQL++ just as you would any other - typical Unix program. See README-Unix.txt for details. +Prerequisite: Build MySQL +~~~~~~~~~~~~~~~~~~~~~~~~~ + Before you can build MySQL++, you need to build the MySQL client + library from source. This is necessary because Cygwin programs + work best when linked to Cygwin libraries, even though it's + possible to link to some native Windows libraries. You do not + need to build a Cygwin version of the MySQL server; it's still + best to use the native Windows version of that. + + The MySQL client library does not build correctly out of the box. + The best instructions I've found covering the necessary changes + are here: + + http://cygwin.com/ml/cygwin/2004-11/msg00159.html + + I recommend that you use MySQL v4.1.x at this time. Skip the + step changing the pthread stuff in my_thr_init.c, as this change + has already been made in recent versions of MySQL. + + With the changes applied, build and install the client library + like so: + + $ autoreconf --install --verbose --force + $ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ + --infodir=/usr/share/info --mandir=/usr/share/man \ + --disable-shared --without-{debug,readline,libedit,server} + $ make + $ make install + + +Building the Library and Example Programs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + With that done, you can build MySQL++ just as you would any other + typical Unix program. See README-Unix.txt for details. diff --git a/README-MinGW.txt b/README-MinGW.txt index 7c46274..894e4fc 100644 --- a/README-MinGW.txt +++ b/README-MinGW.txt @@ -1,91 +1,103 @@ -Prerequisite: GCC Version -~~~~~~~~~~~~~~~~~~~~~~~~~ - If your MinGW version isn't using at least GCC 3.4.5, it needs - to be updated. Older versions are known to not work with MySQL++. - - -Prerequisite: MySQL C API DLL Import Library -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Before you can build MySQL++ with MinGW, you will need to create - a MinGW-compatible import library for MySQL's C API library. - Using the current default install path for MySQL and assuming - MySQL++ is in c:\mysql++, the commands to do this are: - - cd C:\Program Files\MySQL\MySQL Server 5.0\lib\opt - dlltool -k -d c:\mysql++\libmysqlclient.def -l libmysqlclient.a - - -Prerequisite: MySQL C Development Files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - You'll also need to have MySQL installed, including all the - MySQL C development files; MySQL++ is built atop this library. - The MySQL server installer has, in the past, sometimes installed - these by default, and sometimes not. You may need to do a custom - install to get them. - - The MySQL++ Makefile assumes that you installed the MySQL - development files in C:\Program Files\MySQL\MySQL Server 5.0\ - If not, you have two options. - - The simplest is to edit Makefile.mingw. This is a generated - file, but if that's all the only change to MySQL++ you need, - it works fine. - - If you're doing deeper work on MySQL++, you should change the - variable MYSQL_WIN_DIR at the top of mysql++.bkl instead. Then to - generate Makefile.mingw from that file, you will need the Win32 - port of Bakefile from http://bakefile.org/ The command to do - that is: - - bakefile_gen -f mingw - - -Building the Library and Example Programs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - With the prerequisites above taken care of, you can build MySQL++ - with this command: - - mingw32-make -f Makefile.mingw - - Notice that we're using the MinGW-specific version of GNU make, - not the Cygwin or MSYS versions. Many things will break otherwise: - path separator handling, shell commands used by the Makefile, etc. - - Once the library is built, you should run the examples. - At minimum, run resetdb and simple1. - - Once you're satisfied that the library is working correctly, you - can run the install.bat file at the project root to automatically - install the library files and headers in subdirectories under - c:\mysql++. - - -Cygwin and MinGW Coexistence -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - It's possible to have both Cygwin and MinGW installed and build - with the MinGW tools without interference from the Cygwin bits. - The main thing you have to take care of is that MinGW's bin - directory must precede the Cygwin bin directory in the PATH, - so that its tools are found first. If you use Cygwin's bash - as a command shell in preference to the DOS-like cmd.exe, you - can use this shell script to temporarily set the environment to - "MinGW mode" and make it easy to get back to "Cygwin mode": - - #!/bin/sh - PATH=/c/mingw/bin:/c/windows:/c/windows/system32:/c/cygwin/bin - echo "Say 'exit' to leave MinGW shell and restore Cygwin environment." - /usr/bin/bash --rcfile ~/.mingwrc - - I recommend having at least this in the ~/.mingwrc file: - - alias make=mingw32-make - PS1='MinGW: \W \$ ' - - The prompt change reminds you that you are in a sub-shell set up - for MinGW. The alias for 'make' ensures you don't accidentally - run Cygwin's make, which won't work with Makefile.mingw. We could - just leave /c/cygwin/bin out of the environment, but there are - Cygwin tools we want access to, like vim. As long as all the - MinGW ones override those Cygwin also provides, we don't need to - worry about having both in the PATH. Besides, having the alias - is nice for those who have 'make' committed to muscle memory. +Prerequisite: GCC Version +~~~~~~~~~~~~~~~~~~~~~~~~~ + If your MinGW version isn't using at least GCC 3.4.5, it needs + to be updated. Older versions are known to not work with MySQL++. + + +Prerequisite: MySQL C Development Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + MySQL++ is built atop MySQL's C API library, so you need to have + MySQL installed on your development system to get the current C API + development files. + + If you do a default installation of MySQL, the development files + probably won't be installed. As of this writing you have to do + either a Complete or Custom install to get these files. (They keep + changing the way the Windows installer works, so this may not be + true any more by the time you read this.) + + The MySQL++ Makefile assumes that you installed MySQL in + + C:\Program Files\MySQL\MySQL Server 5.0\ + + If not, you have two options. + + The simplest is to edit Makefile.mingw. This is a generated + file, but if that's all the only change to MySQL++ you need, + it works fine. + + If you're doing deeper work on MySQL++, you should change the + variable MYSQL_WIN_DIR at the top of mysql++.bkl instead. Then to + generate Makefile.mingw from that file, you will need the Win32 + port of Bakefile from http://bakefile.org/ The command to do + that is: + + bakefile_gen -f mingw + + +Prerequisite: MySQL C API DLL Import Library +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Before you can build MySQL++ with MinGW, you will need to create + a MinGW-compatible import library for MySQL's C API library. + Using the current default install path for MySQL and assuming + MySQL++ is in c:\mysql++, the commands to do this are: + + cd C:\Program Files\MySQL\MySQL Server 5.0\lib\opt + dlltool -k -d c:\mysql++\libmysqlclient.def -l libmysqlclient.a + + +Building the Library and Example Programs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + With the prerequisites above taken care of, you can build MySQL++ + with this command: + + mingw32-make -f Makefile.mingw + + Notice that we're using the MinGW-specific version of GNU make, not + the Cygwin or MSYS versions. Many things will break otherwise: path + separator handling, shell commands used by the Makefile, etc. + + Speaking of Cygwin and MSYS, if you have either these or any other + Unix emulation environment installed, be sure their executables + aren't in the PATH when building MySQL++. MinGW's version of GNU + make does some funny things if it thinks it's running in the + presence of Unixy tools, which will break the MySQL++ build. + + Once the library is built, you should run the examples. At minimum, + run resetdb and simple1. + + Once you're satisfied that the library is working correctly, you can + run the install.bat file at the project root to automatically + install the library files and headers in subdirectories under + c:\mysql++. + + +Cygwin and MinGW Coexistence +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + It's possible to have both Cygwin and MinGW installed and build with + the MinGW tools without interference from the Cygwin bits. The main + thing you have to take care of is that MinGW's bin directory must + precede the Cygwin bin directory in the PATH, so that its tools are + found first. If you use Cygwin's bash as a command shell in + preference to the DOS-like cmd.exe, you can use this shell script to + temporarily set the environment to "MinGW mode" and make it easy to + get back to "Cygwin mode": + + #!/bin/sh + PATH=/c/mingw/bin:/c/windows:/c/windows/system32:/c/cygwin/bin + echo "Say 'exit' to leave MinGW shell and restore Cygwin environment." + /usr/bin/bash --rcfile ~/.mingwrc + + I recommend having at least this in the ~/.mingwrc file: + + alias make=mingw32-make + PS1='MinGW: \W \$ ' + + The prompt change reminds you that you are in a sub-shell set up for + MinGW. The alias for 'make' ensures you don't accidentally run + Cygwin's make, which won't work with Makefile.mingw. We could just + leave /c/cygwin/bin out of the environment, but there are Cygwin + tools we want access to, like vim. As long as all the MinGW ones + override those Cygwin also provides, we don't need to worry about + having both in the PATH. Besides, having the alias is nice for + those who have 'make' committed to muscle memory. diff --git a/configure.ac b/configure.ac index 5af29e6..22e34f4 100644 --- a/configure.ac +++ b/configure.ac @@ -14,7 +14,7 @@ # USA # Standard autotools stuff -AC_INIT(mysql++, 3.0.2, plusplus@lists.mysql.com, mysql++) +AC_INIT(mysql++, 3.0.3, plusplus@lists.mysql.com, mysql++) AC_CONFIG_HEADER(config.h) AC_DISABLE_STATIC AC_CANONICAL_SYSTEM diff --git a/doc/userman/userman.dbx b/doc/userman/userman.dbx index 4d76640..2ddc94a 100644 --- a/doc/userman/userman.dbx +++ b/doc/userman/userman.dbx @@ -4,7 +4,7 @@
- MySQL++ v3.0.2 User Manual + MySQL++ v3.0.3 User Manual diff --git a/lib/mystring.cpp b/lib/mystring.cpp index 415a202..05eec4e 100644 --- a/lib/mystring.cpp +++ b/lib/mystring.cpp @@ -2,7 +2,7 @@ mystring.cpp - Implements the String class. Copyright (c) 1998 by Kevin Atkinson, (c) 1999-2001 by MySQL AB, and - (c) 2004-2007 by Educational Technology Resources, Inc. Others may + (c) 2004-2008 by Educational Technology Resources, Inc. Others may also hold copyrights on code in this file. See the CREDITS file in the top directory of the distribution for details. @@ -27,6 +27,7 @@ #include "mystring.h" #include "query.h" +#include #include #include @@ -49,7 +50,8 @@ int String::compare(const String& other) const { if (other.buffer_) { - return compare(0, length(), other.buffer_->data()); + return compare(0, std::max(length(), other.length()), + other.buffer_->data()); } else { // Other object has no buffer, so we are greater unless empty or @@ -62,7 +64,7 @@ String::compare(const String& other) const int String::compare(const std::string& other) const { - return compare(0, length(), other.data()); + return compare(0, std::max(length(), other.length()), other.data()); } @@ -76,7 +78,7 @@ String::compare(size_type pos, size_type num, std::string& other) const int String::compare(const char* other) const { - return compare(0, length(), other); + return compare(0, std::max(length(), strlen(other)), other); } diff --git a/lib/query.cpp b/lib/query.cpp index 1763184..3824d77 100644 --- a/lib/query.cpp +++ b/lib/query.cpp @@ -489,13 +489,13 @@ Query::store(const char* str, size_t len) return StoreQueryResult(res, conn_->driver(), throw_exceptions()); } else { - // Either result set is empty (which is copacetic), or there - // was a problem returning the result set (which is not). If - // caller knows the result set will be empty (e.g. query is - // INSERT, DELETE...) it should call exec{ute}() instead, but - // there are good reasons for it to be unable to predict this. - copacetic_ = conn_->driver()->result_empty(); - if (copacetic_) { + // Either result set is empty, or there was a problem executing + // the query or storing its results. Since it's not an error to + // use store() with queries that never return results (INSERT, + // DELETE, CREATE, ALTER...) we need to figure out which case + // this is. (You might use store() instead of execute() for + // such queries when the query strings come from "outside".) + if (copacetic_ = (conn_->errnum() == 0)) { if (parse_elems_.size() == 0) { // Not a template query, so auto-reset reset(); @@ -610,13 +610,9 @@ Query::use(const char* str, size_t len) return UseQueryResult(res, conn_->driver(), throw_exceptions()); } else { - // Either result set is empty (which is copacetic), or there - // was a problem returning the result set (which is not). If - // caller knows the result set will be empty (e.g. query is - // INSERT, DELETE...) it should call exec{ute}() instead, but - // there are good reasons for it to be unable to predict this. - copacetic_ = conn_->driver()->result_empty(); - if (copacetic_) { + // See comments in store() above for why we distinguish between + // empty result sets and actual error returns here. + if (copacetic_ = (conn_->errnum() == 0)) { if (parse_elems_.size() == 0) { // Not a template query, so auto-reset reset(); diff --git a/lib/sql_types.h b/lib/sql_types.h index 7f700e4..9c0bd9c 100644 --- a/lib/sql_types.h +++ b/lib/sql_types.h @@ -36,6 +36,10 @@ #include +#if !defined(MYSQLPP_NO_STDINT_H) +# include +#endif + namespace mysqlpp { #if !defined(DOXYGEN_IGNORE) @@ -59,7 +63,6 @@ namespace mysqlpp { #else // Assume a system where C99 is supported in C++ in advance of // actual standardization, so we can do this portably. -# include typedef tiny_int sql_tinyint; typedef tiny_int sql_tinyint_unsigned; typedef int16_t sql_smallint; diff --git a/mysql++.bkl b/mysql++.bkl index 2b24989..7b63c06 100644 --- a/mysql++.bkl +++ b/mysql++.bkl @@ -54,7 +54,7 @@ mysqlpp$(DEBUG_SUFFIX) mysqlpp$(DEBUG_SUFFIX) - 3.0.2 + 3.0.3 lib/beemutex.cpp diff --git a/test/string.cpp b/test/string.cpp index 7abce1a..a9e7214 100644 --- a/test/string.cpp +++ b/test/string.cpp @@ -219,41 +219,79 @@ test_string_equality(const mysqlpp::String& s, std::string value) } +// Same as above, but for two String objects +static bool +test_string_equality(const mysqlpp::String& s1, + const mysqlpp::String s2) +{ + if (s1 == s2) { + return true; + } + else { + std::cerr << "String(\"" << s1 << "\") != String(\"" << + s2 << "\"), but should be equal!" << std::endl; + return false; + } +} + + +// Inverse of above. +static bool +test_string_inequality(const mysqlpp::String& s1, + const mysqlpp::String& s2) +{ + if (s1 != s2) { + return true; + } + else { + std::cerr << "String(\"" << s1 << "\") == String(\"" << + s2 << "\") but shouldn't be!" << std::endl; + return false; + } +} + + int main(int, char* argv[]) { try { int failures = 0; - mysqlpp::String empty; + mysqlpp::String definit; + mysqlpp::String empty(""); mysqlpp::String zero("0"); mysqlpp::String nonzero("42"); mysqlpp::String intable1("42."); mysqlpp::String intable2("42.0"); mysqlpp::String nonint("42.1"); - failures += test_equality(empty, mysqlpp::Date()) == false; - failures += test_equality(empty, + failures += test_equality(definit, mysqlpp::Date()) == false; + failures += test_equality(definit, mysqlpp::DateTime(0, 0, 0, 0, 0, 0)) == false; - failures += test_equality(empty, mysqlpp::Time()) == false; - failures += test_equality(empty, false) == false; + failures += test_equality(definit, mysqlpp::Time()) == false; + failures += test_equality(definit, false) == false; failures += test_equality(nonzero, true) == false; - failures += test_numeric(empty, 0) == false; + failures += test_numeric(definit, 0) == false; failures += test_numeric(zero, 0) == false; failures += test_numeric(nonzero, 42) == false; - failures += test_quote_q(empty, true) == false; + failures += test_quote_q(definit, true) == false; failures += test_quote_q(mysqlpp::String("1", typeid(int)), false) == false; failures += test_float_conversion() == false; failures += test_float_conversion() == false; - failures += test_int_conversion(empty, false) == false; + failures += test_int_conversion(definit, false) == false; failures += test_int_conversion(zero, false) == false; failures += test_int_conversion(nonzero, false) == false; failures += test_int_conversion(intable1, false) == false; failures += test_int_conversion(intable2, false) == false; failures += test_int_conversion(nonint, true) == false; failures += test_null() == false; - failures += test_string_equality(empty, "") == false; + failures += test_string_equality(definit, empty) == false; + failures += test_string_equality(empty, definit) == false; + failures += test_string_equality(definit, "") == false; failures += test_string_equality(zero, "0") == false; + failures += test_string_inequality(definit, zero) == false; + failures += test_string_inequality(zero, definit) == false; + failures += test_string_inequality(empty, nonzero) == false; return failures; }