This thread interacts with another current thread: the one about MS-SQL database support. As I mentioned there, adodbapi is capable of accessing any ODBC compliant data source. MySQL is one of those. adodbapi is Python 3 compliant, and I have been using MySQL databases from Python 3 for several years.
If django supported adodbapi as a connection method -- separated from its use as a connection method specifically for the Microsoft SQL engine -- then it could also be used to reach MySQL and any other database engine people needed. I should be able to use adodbapi rather than psycopg2, for example, if the hooks were in place. On Linux, I should be permitted to select a prominent commercial ODBC product to do the same job, if I wanted to.
At the present time, the specification of the database engine is implied by selecting the backend in settings.py. There is no convenient way of saying "I expect to be using connection method "X" to hook with engine "Y". The driver-to-engine coupling has always been one-to-one. I suspect that there are places deep withing django where this simplification has been used to advantage. However, the two things should really be uncoupled. Is it important? No. Might it have some presently unforseen advantages? I suspect so.
If the two Oracle database interfaces were to be re-tasked as supported options, rather than part of the core, then the driver-to-engine coupling would become looser. In the end, it ought to be possible for the selection of the engine to be deferred until after the database is actually connected. Neither ADO nor ODBC actually know which engine they are talking to until the connection is complete. After connection, I can look at the connection.dbms_name attribute and I can see which engine I am connected to. If the engine turns out to be postgresql, should I not be able to hook to the correct SQL compiler and have everything just work?
Then, with this looser coupling, We could separate the testing (and support) of different engines on different operating systems on different Python versions.
--
Vernon Cole
On Sunday, March 10, 2013 5:32:02 PM UTC-6, Norberto Bensa wrote:
Hello,
I wanted to run Django with Python 3 but mysql was a showstopper until today. Thanks to G+ I found a few links of interest:
So I git-cloned django and m4p3 but I got a problem.
'use_unicode' is an invalid keyword argument for this function| Request Method: | GET |
|---|
| Request URL: | http://localhost:8080/propietario/ |
|---|
| Django Version: | 1.6.dev20130310222819 |
|---|
| Exception Type: | TypeError |
|---|
| Exception Value: | 'use_unicode' is an invalid keyword argument for this function |
|---|
| Exception Location: | /home/ubuntu/.virtualenvs/test3/git/MySQL-for-Python-3/MySQLdb/connections.py in __init__, line 175 |
|---|
| Python Executable: | /home/ubuntu/.virtualenvs/test3/bin/python |
|---|
| Python Version: | 3.2.3 |
|---|
I thought, well, let's disable use_unicode in my settings.py. I added OPTIONS: { 'use_unicode': False } to DATABASES.default, but no way. Same error. So I patched django/db/backends/mysql/base.py:DatabaseWrapper:get_connection_params() and commented 'use_unicode':True. And now I can use Django, Mysql, and Python 3
The question is: Is there any option I'm overlooking and this mix can be used with patching Django or is Mysql+python3 just not supported (for now)?
Thanks!
Norberto