MySQL Connector/Python support
geertjanvdk
And best wishes for 2010! I am the maintainer, Geert Vanderkelen, of
MySQL Connector/Python at Sun Microsystems.
First, thanks for taking MySQL Connector/Python and putting it in as a
dialect in SQL Alchemy, great stuff already! This will be great for
other projects using SQLAlchemy. Very cool!
Few things:
* Could you change the dialect name from 'myconnpy' to
'mysqlconnector' or something like that. 'MySQL' should be first in
the name, as this is most 'official' thing the MySQL Team has done for
Python. Would be great. 'myconnpy' is just the short tag on LaunchPad.
* Checking the current trunk of SQLAlchemy, it's using a quite old
version of MySQL Connector/Python. We've done some development
releases lately, and there will be more. The bug mentioned, was fixed
though!
Maybe, if I'll find time, I'll check the code myself and do some work
there too.
I'm looking forward for ideas, and improvements for MySQL Connector/
Python to make the integration easier. If you guys have ideas, please
post them on LaunchPad.
Cheers,
Geert
Michael Bayer
> Hello,
>
> And best wishes for 2010! I am the maintainer, Geert Vanderkelen, of
> MySQL Connector/Python at Sun Microsystems.
>
> First, thanks for taking MySQL Connector/Python and putting it in as a
> dialect in SQL Alchemy, great stuff already! This will be great for
> other projects using SQLAlchemy. Very cool!
>
> Few things:
> * Could you change the dialect name from 'myconnpy' to
> 'mysqlconnector' or something like that. 'MySQL' should be first in
> the name, as this is most 'official' thing the MySQL Team has done for
> Python. Would be great. 'myconnpy' is just the short tag on LaunchPad.
renamed to "mysqlconnector" in r6613.
> * Checking the current trunk of SQLAlchemy, it's using a quite old
> version of MySQL Connector/Python. We've done some development
> releases lately, and there will be more. The bug mentioned, was fixed
> though!
There were two bugs that were being worked around, and for some reason the
hyperlink in the source code were all for just one bug; additionally I
can't seem to find any of those bugs on the launchpad site which doesn't
seem to have any way to show "resolved" bugs, or they were removed, not
really sure. Anyway I've removed both workarounds in r6613 - using
cursor.lastrowid now, using dbapi.paramstyle as is without forcing to
positional. Feel free to try out trunk and run the unit tests,
specifying uri=mysql+mysqlconnector://user:name@host/db !
geertjanvdk
On Jan 4, 5:29 pm, "Michael Bayer" <mike...@zzzcomputing.com> wrote:
..
> > * Could you change the dialect name from 'myconnpy' to
> > 'mysqlconnector' or something like that. 'MySQL' should be first in
> > the name, as this is most 'official' thing the MySQL Team has done for
> > Python. Would be great. 'myconnpy' is just the short tag on LaunchPad.
>
> renamed to "mysqlconnector" in r6613.
Thanks so much for this! I think that name will make it more clear
what it is. There was additional myconnpy import in __init__.py,
which I corrected in the patch below.
> > * Checking the current trunk of SQLAlchemy, it's using a quite old
> > version of MySQL Connector/Python. We've done some development
> > releases lately, and there will be more. The bug mentioned, was fixed
> > though!
>
> There were two bugs that were being worked around, and for some reason the
> hyperlink in the source code were all for just one bug; additionally I
> can't seem to find any of those bugs on the launchpad site which doesn't
> seem to have any way to show "resolved" bugs, or they were removed, not
> really sure. Anyway I've removed both workarounds in r6613 - using
> cursor.lastrowid now, using dbapi.paramstyle as is without forcing to
> positional. Feel free to try out trunk and run the unit tests,
> specifying uri=mysql+mysqlconnector://user:name@host/db !
Bugs should be kept on Launchpad, but lets see how we can make it work
with the development release of MySQL Connector/Python.
One change I did was _get_server_version_info(), see in patch
below.
I ran the tests, not sure how normal the number of errors is :)
(Using MySQL Connector/Python 0.1.2-dev)
shell> nosetests --dburi=mysql+mysqlconnector://root:@localhost/
sqlalchemy
..
----------------------------------------------------------------------
Ran 784 tests in 49.766s
FAILED (errors=499, failures=2)
Looking into a few.
-Geert
Index: lib/sqlalchemy/dialects/mysql/__init__.py
===================================================================
--- lib/sqlalchemy/dialects/mysql/__init__.py (revision 6614)
+++ lib/sqlalchemy/dialects/mysql/__init__.py (working copy)
@@ -1,4 +1,4 @@
-from sqlalchemy.dialects.mysql import base, mysqldb, oursql, pyodbc,
zxjdbc, myconnpy
+from sqlalchemy.dialects.mysql import base, mysqldb, oursql, pyodbc,
zxjdbc, mysqlconnector
# default dialect
base.dialect = mysqldb.dialect
Index: lib/sqlalchemy/dialects/mysql/mysqlconnector.py
===================================================================
--- lib/sqlalchemy/dialects/mysql/mysqlconnector.py (revision 6614)
+++ lib/sqlalchemy/dialects/mysql/mysqlconnector.py (working copy)
@@ -57,13 +57,7 @@
def _get_server_version_info(self, connection):
dbapi_con = connection.connection
- version = []
- r = re.compile('[.\-]')
- for n in r.split(dbapi_con.get_server_version()):
- try:
- version.append(int(n))
- except ValueError:
- version.append(n)
+ version = dbapi_con.get_server_version()
return tuple(version)
def _detect_charset(self, connection):
Michael Bayer
>
> Thanks so much for this! I think that name will make it more clear
> what it is. There was additional myconnpy import in __init__.py,
> which I corrected in the patch below.
oops, yeah , that is in r6615 thx
> One change I did was _get_server_version_info(), see in patch
> below.
that change is also in r6615.
>
> I ran the tests, not sure how normal the number of errors is :)
> (Using MySQL Connector/Python 0.1.2-dev)
>
> shell> nosetests --dburi=mysql+mysqlconnector://root:@localhost/
> sqlalchemy
> ..
> ----------------------------------------------------------------------
> Ran 784 tests in 49.766s
>
> FAILED (errors=499, failures=2)
For MySQL dialects there should be no errors or failures - at most there
may be a handful of errors/failures which correspond to tests that should
be skipped for that DBAPI, although if you're getting one of those which
leads the database into an invalid state it may result in a cascade of
many failures.
It's more likely that the mysqlconnector dialect has some outdated
elements in it which need to be updated, or perhaps that there's some
DBAPI behavior not yet provided by mysqlconnector that SQLA is expecting.
A log of tests running with MySQLdb as well as OurSQL is at
http://paste.pocoo.org/show/161970/
geertjanvdk
Thanks for the quick changes there!
On Jan 4, 7:45 pm, "Michael Bayer" <mike...@zzzcomputing.com> wrote:
..
> For MySQL dialects there should be no errors or failures - at most there
> may be a handful of errors/failures which correspond to tests that should
> be skipped for that DBAPI, although if you're getting one of those which
> leads the database into an invalid state it may result in a cascade of
> many failures.
OK, so I guess we got still a long way to go. :)
I ran tests with MySQLdb but ran in lots of failures, but I'm
concentrating on MySQL Connector/Python for now.
One thing I can't figure out is why tests are not cleaning
up or dropping tables. Works apparently good with MySQLdb, but
not with our Connector. Something for tomorrow on the train.
> It's more likely that the mysqlconnector dialect has some outdated
> elements in it which need to be updated, or perhaps that there's some
> DBAPI behavior not yet provided by mysqlconnector that SQLA is expecting.
> A log of tests running with MySQLdb as well as OurSQL is athttp://paste.pocoo.org/show/161970/
Ah, attached another small patch, no need to parse, if you
got the errno right from the exception :)
-Geert
===================================================================
--- lib/sqlalchemy/dialects/mysql/mysqlconnector.py (revision 6615)
+++ lib/sqlalchemy/dialects/mysql/mysqlconnector.py (working copy)
@@ -66,11 +66,10 @@
return connection.connection.get_characterset_info()
def _extract_error_code(self, exception):
- m = re.compile(r"\(.*\)\s+(\d+)").search(str(exception))
- c = m.group(1)
- if c:
- return int(c)
- else:
+ try:
+ if exception.errno > -1:
+ return int(exception.errno)
+ except:
return None