MySQL Connector/Python v1.0.5 beta is now available for download from the MySQL website. This version is feature complete and we welcome and appreciate feedback and bug reports.

We’re also interested in hearing your feedback for future enhancements. Let us know how you’re using the connector too, especially if you are using it with Django, SQLAlchemy and similar Python technologies.

A few things have changed since the last development releases and we hope the manual shipping with the Connector/Python distribution (and also available online soon) will help you get up to speed.

Here are a few important changes that might be incompatible with current scripts using the now obsolete development releases v0.3.2 and …

I’m currently figuring out how to name the MySQL Connector/Python distributions so it works well with PyPi. Source archives would be named like mysql-connector-python-X.Y.Z.tar.gz.

The ‘name’ metadata would be ‘MySQL Connector Python’, thus without any underscores or dashes. This works OK, but if people have objections, please leave a comment.

It’s been released. Use this with NIST::NVD 1.00.00 and you will be able to perform immediate look-ups of CVE and CWE data given a CPE URN. For instance:

cjac@foxtrot:/usr/src/git/f5/NIST-NVD-Store-SQLite3$ perl Makefile.PL ; make ; make test ; cjac@foxtrot:/usr/src/git/f5/NIST-NVD-Store-SQLite3$ perl -MNIST::NVD::Query -MData::Dumper -e '
$q = NIST::NVD::Query->new(store    => q{SQLite3},database => q{t/data/nvdcve-2.0.db});
$cve_list = $q->cve_for_cpe( cpe => q{cpe:/a:microsoft:ie:7.0.5730.11} );
print Data::Dumper::Dumper { cve_list => $cve_list, first_cvss => $q->cve( cve_id => $cve_list->[0] )->{q{vuln:cvss}} }
'
$VAR1 = {
          'cve_list' => [
                          'CVE-2002-2435',
                          'CVE-2010-5071'
                        ],
          'first_cvss' => {
                            'cvss:base_metrics' => { …

I’m leaving myself some room for bug fixes. It works for us in house. I would love to help others to give it a try. especially those who could benefit from making nearly immediately answered queries to the NIST’s NVD database.

The code in this release cannot by itself track the feed from the feds in real time. The nvd entry loader needs a little bit of love in the area of record merging before this starts working. It’s on my TODO list.

I’m sorry for the outage of git.colliertech.org. I’ll get that back up here shortly. In the meantime, feel free to grab it from this location while the CPAN indexes and processes my submission.

http://www.colliertech.org/federal/NIST/NIST-NVD-1.00.00.tar.bz2

don’t forget to check the cryptographic signature:

…

Two extra tips when you try to (manually) bootstrap MySQL on Windows from the command line:

1. When bootstrapping, use --no-defaults or --defaults-file.
2. Use --standalone when starting the MySQL server.

The first point really bugged me yesterday. I’m used to installing MySQL manually and having no option files available where MySQL would read them by default.

On Windows, however, I used the MySQL installer. So, when I launch unit testing for Connector/Python it bugged me saying log files of InnoDB didn’t match the configuration. This is indeed a newbie error..

In this blog we discuss invalid dates in MySQL, how to retrieve them using Connector/Python and we raise the question: Should Connector/Python raise an error or just keep returning None on invalid dates?

If you run MySQL without proper SQL Modes, you will be able to update and
read invalid dates such as ’2012-06-00′. If you’ve payed attention the past decade, you’ll know that you can prevent this configuring your MySQL server setting SQL Mode to ‘TRADITIONAL’.

Now, the problem if this is allowed, how do we get invalid dates using MySQL Connector/Python?

Lets look at an example inserting an invalid date and trying to read it again using MySQL Connector/Python:

>>> cur = …

Last couple of week I was looking for an easier approch to manage the Databases created on Amazon RDS instances. I had to run through a tedious set of steps in carrying out routine stuff like introducing new updates, taking daily backups and moving it to an Amazon S3 bucket, etc… Before getting into touch […]

We have moved bugs for MySQL Connector/Python from Launchpad to the MySQL Bugs website http://bugs.mysql.com. Reports which are (probably) fixed in newer code were not taken with. If there is a bug which you really want to get tracked: please report it again.

Please use the MySQL Bugs website to report problems using MySQL Connector/Python. To see a list of active reports, click here.

…

I published an SQLite3 storage back-end to NIST::NVD on the CPAN. It’s pretty quick. About as fast as the DB_File one, but without the down side of being tied to DB_File. It shouldn’t be too difficult to re-factor this code to any DBI-based database. MariaDB anyone?

I know it works on Debian. The nightly CPAN test results should come back shortly and I’ll find out how well it works on other platforms.

There have been some request to have some reconnect possibilities in Connector/Python. I’m wondering now whether there should be some automatic reconnect on certain errors within the database driver.

My personal feeling is to have no automatic reconnect within Connector/Python and the programmer has to come up with retrying transactions herself.

For example:

        cnx.disconnect() # For testing..
        tries = 2
        while tries > 0:
                tries -= 1
                try:
                        cursor.execute("INSERT INTO t1 (c1) VALUES ('ham')")
                        cnx.commit()
                except mysql.connector.InterfaceError:
                        if tries == 0:
                                print "Failed inserting data after retrying"
                                break
                        else:
                                print …