Last week I took SQLAlchemy v0.6 out of its trunk and tested it again with our MySQL Connector/Python. And surprise! SQLAlchemy comes with a 'dialect' supporting it! Nice!

However, we're still a long way on making it work. I found some additional problems which need to be fixed first.

shell> nosetests --dburi=mysql+mysqlconnector://root:@localhost/sqlalchemy \
    test/dialect/test_mysql.py
..
Ran 32 tests in 4.507s

FAILED (errors=6, failures=1)

Oh, there were more errors and failures and all that due to bugs in MySQL Connector/Python. There were …

Something to keep you warm during cold winter nights, or cool during hot summer days: a chessboard in MySQL!

Note: You should see chess pieces here below. If not, you're not watching it using UTF-8, or get yourself a good browser!

CREATE TABLE `chessboard` (
  `x` tinyint unsigned NOT NULL,
  `a` enum('','♔','♕','♖','♗','♘','♙','♚','♛','♜','♝','♞','♟'),
  `b` enum('','♔','♕','♖','♗','♘','♙','♚','♛','♜','♝','♞','♟'),
  `c` enum('','♔','♕','♖','♗','♘','♙','♚','♛','♜','♝','♞','♟'),
  `d` enum('','♔','♕','♖','♗','♘','♙','♚','♛','♜','♝','♞','♟'),
  `e` enum('','♔','♕','♖','♗','♘','♙','♚','♛','♜','♝','♞','♟'),
  `f` enum('','♔','♕','♖','♗','♘','♙','♚','♛','♜','♝','♞','♟'),
  `g` …

Here is two small examples showing the wonderful world of character sets and unicode using MySQL Connector/Python (using 0.1.2-devel and up) in both Python v2.x and v3.1.

The following table will be used with default character set latin7, i.e. ISO-8859-13. Just setting it to UTF-8 would be bit boring!

CREATE TABLE `latin7test` (
  `c1` varchar(60) DEFAULT NULL
) DEFAULT CHARSET=latin7

Things to note for the code listed below are:

• We're using charset='latin7' as connection option. This is important!
• We set use_unicode=True so the results coming from MySQL are encoded to unicode. For testing, we disable this later.
…

MySQL Connector/Python 0.1.2-devel is a quick follow-up release for 0.1.1 fixing a few problems around character sets and unicode.

You can download Connector/Python from LaunchPad.

Release notes for MySQL Connector/Python 0.1.2-devel

o Fixing unicode usage for both Python 2.4+ and 3.1
  * Setting 'use_unicode' at connection time is now
    working.
  * conversion.py: removing regular expression for
    quoting backslashes.
  * Adding test case for bug lp:499410
  
  Py3k specific:
  * Strings from MySQL are decoded to the given character
    when use_unicode is false
  * The statement is encoded just before sending it to the
    MySQL server. Internally, all is done in …

The second development release of MySQL Connector/Python comes with support for Python v3.1!

I thought of making two distributions of MySQL Connector/Python, but then it would have been messy with versions and packaging. So what you get now is 2-in-1 and the installation script should be smart enough to figure it out.

Please, if you find any issues, bugs or have suggestions: report them here https://bugs.launchpad.net/myconnpy

Download

From LaunchPad!

Release notes

Added Python v3.1 support
* The subdirectory/module py3k/ contains Connector/Python compatible
  with Python v3.1.1.
* setup.py will install the correct Connector/Python distribution
  depending on …

Keeping a MySQL installation up and running can be quite tricky at times, especially when having many servers to manage and monitor. In the replication tutorials at the annual MySQL Users' Conference, we demonstrate how to set up replication appropriately and also how to handle various issues that can arise.

Many of these procedures are routine: bring down the server, edit the configuration file, bring the server up again, start a mysql client and add a user, etc.

It has always annoyed me that these procedures are perfect candidates for automation, but that we do not have the necessary interfaces to manipulate an entire installation of MySQL servers.

If there were an interface with a relatively small set of primitives—re-directing servers, bringing servers down, add a line to the configuration file, etc.—it would be possible to create pre-canned procedures that can just be executed.

To that end, …

Today we're releasing MySQL Connector/Python 0.1.0-devel. This is the first in a serie of development snapshots aimed to get more people trying it out and reporting problems. This is not a production-ready release, but it should work on all Unices and Windows which has Python 2.4 or later installed. (No, no Py3K, yet!)

You can download it from Launchpad: there is a .tar.gz and .zip

There will be documentation and tutorial, but installation is as easy as pie (pun intended):

 shell> tar xzf mysql-connector-python-0.1.0-devel.tar.gz
 shell> cd mysql-connector-python-0.1.0-devel
 shell> python ./setup.py install

If you …

Hi all!

I’ve been reading through the requested features for the new client on the wiki here:

• Proposed Client Features
• BOOTS Console API Design

I think all the stuff on that link is excellent so far. I’d also like to request a feature that I think will be a really cool timesaver for DBAs and developers using Drizzle.

Macro Support

Remember, “way back when” you used Microsoft Excel and were able to start recording your actions, then when you stopped recording, Excel would store a “macro” of your actions that you could subsequently replay?

I think this would be incredibly useful for folks who do repetitive work in the console.

Sure, I know, I …

I'm currently planning a first 'alpha' release of MySQL Connector/Python, but I'm now doubting whether the naming and installation of the module is actually good.

Currently, the module lives, in site-packages/mysql/connector/, or import mysql.connector. Since this is an official MySQL, sorry, Sun Microsystems, project, I thought that the 'parent' module mysql would be good enough.

But is it? Would it break your modules with the same name?

The idea was to make more tools for Python and have them all under the mysql module, but maybe we need a smarter name for this? Maybe sunmysql/connector?

Comments are welcome! You can also email me directly (if you can figure out the cryptic anti-spam): geert_dot_vanderkelen_APETAIL_sun_dot_com.

With IntelliJ now being available under an Open Source license, developers have another option to choose from when it comes to Java-based IDEs/Frameworks (Eclipse and NetBeans being the other two prominent ones). Choice is always good, and being an Open Source enthusiast, I of course welcome JetBrain's move!

However, as I'm not really a heavy GUI-based IDE user myself, I can't really comment on which one is the best. These kind of discussions tend to turn into a Holy War anyway... In the end it's likely that each of them gets the job done and you have to come to your own conclusions, based on your personal preference and requirements.

I personally would be interested in …