What is it?
Well I've just found that the Objective-C language with the Cocoa framework was a great environment to develop with - but - there was no support for MySQL, which I like a lot as well. I decided to use the C API of MySQL to make an Objective-C API, and to release it so others can use it as well.
Updates
- 26 February 2006 Released the first bug fixes. The 3.0.0 version was getting an error when trying to get the server's timezone (for TIMESTAMP conversion to client timezone) with older version of the MySQL server.
Added some few more text encoding conversion (most of the new ones were kindly provided by Lorenz Textor, author of CocoaMySQL). - 02 February 2006 Second redesign of the website, modifying mostly the CSS. Put the current version online. Still some links are missing and documentation is not here, but should come in the coming days.
Also further prepared the Subversion repository. - 30 January 2006 Hard work to get the version 3.0 out. Got evrything together, as a first try out, and put it on the server. The new version is renamed MCPKit, and droped one of the option (no version using dynamic version of libmysqlclient anymore).
Still have to take care of finishing up the new version of the website. - 09 January 2006 Upgraded the website look and organisation. Dave Winter was kind enough to provide a very nice starting point for the re-looking. Still, I think MySQL-Cocoa needs a proper logo; I'd be very happy if someone wants to propose one!
I'm also moving away definitely from CVS to use the excellent subversion (which indeed I've been using on the new version for the last year). When this will be finished the svn server will be at https://www.chocolatnoir.net/svn/mysql-cocoa (but not there yet). - 09 August 2004 Corrected a small bug in the new method
-quoteObject:
, it was not taking care ofnil
orNSNull
object, now it will return the stringNULL
(without surrounding quotes) for these cases. This is version 2.3.1. Normally the API documentation should be updated to the latest version of the framework as of today. -
05 August 2004 Aaron Jacobs pointed me to the solution of the signed/unsigned integer (which indeed was already in a mail from Lorenz Textor). This also gave me the way to discriminate between
TEXT
andBLOB
columns. After implementing the bug fixes, the version 2.3.0 of the framework is now released, the new features/bug fixes are:- Integers : All integers should now be correctly be converted in NSNumber. Indeed I had to implement a NSNumber subclass to handle properly the unsigned numbers as the Foundation NSNumber lass does not retain if the stored number is signed or not (if one create a NSNumber with a large unsigned int, and outputs it later, the output is negative). Now even large UNIGNED BIGINT should be output correctly positive.
- TEXT/BLOB : Now the framework is able to discriminate between these two types (and related SMALL... and LONG...). TEXT will be converted to NSString (using the proper encoding, if the encoding of the MySQL server is supported by Cocoa), whilst BLOB will be converted to NSData.
- quoteObject : This is a new method added to MCPConnection to quote any object, using the object class to know how it should be quoted.
Vanilla, Strawberry or Chocolate... Which flavour do you want:
This info is also available in the README coming with the frameworks (both in source and binaries distributions).
If you are a bit used to MacOS X programming (or if you have read the System Overview from Apple, and more precisely the section dealing with frameworks), you probably already know that there is two main ways to link a framework from the application you are developing:
- System-Wide (or User-Wide) visibility : If the framework is placed in one of the Library/Frameworks subfolder of the system, then any application (including command line tools) can use the framework (only launch by the user if it is in ~/Library/Frameworks).
- Bundled within an application if it is in the Contents/Frameworks/ subfolder of the application bundle of a Cocoa Application (documented here). Then only this application can see the framework
Both of these possibilities have their own advantages and disadvantages. To make it short, on one hand System-Wide frameworks are the only ones that can be used by command line tools (which does not have a bundle, but are rather simple 'UNIX' executables), also if you have a suite of program using the framework you have only one copy on your disk and you are sure all these applications uses exactly the same version of the framework. On the other hand, if you include the framework in the bundle of your application, then it is no longer relying on another component (the user don't need to install one more thing to use your software: it can be used directly 'out of the .dmg').
Because their is no 'one best choice' on this issue, I distribute the framework in two (indeed three) flavours:
- MCPKit_system: System-Wide version of the framework, using the static mysql client library.
- MCPKit_bundled: A version of the framework which is made to be bundled within a Cocoa Application (also statically linked to the mysql client library, so that it is as much self contained as possible).
These two flavours of the frameworks are build from the same sources (indeed they are just two different targets from the same Xcode project), with different options. They are both included in the binary release (version 3.0 and higher).