"manage.py dbshell" broken for MySQL on Windows

[anonymous]

If you run "manage.py dbshell" on Windows when DATABASE_ENGINE is set to "mysql" it looks like it doesn't correctly pass the database details on the command line because it gives this error:

ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (10061)

Strangely it doesn't give this error until just *after* the script has finished and you're back at the cmd prompt. So it looks like it's running mysql in the background! Manually running "mysql --host=blah --user=blah --password=blah dbname" works fine.

[markshep]

(oops - forgot to login when submitting this!)

I just attached a fix.

[markshep]

Looks like it needs doing for other DBs too. Just added a patch for sqlite3.

[Ramiro Morales]

I was going to point in the same direction because some posts to the mailing lists gave me the impression a similar problem happens with sqlite3.exe. Tests I had done at that time showed that it has to do with os.execvp() behavior on Windows.

The proposed solution has the following problems:

• Either the code path or the behavior under Unix/Linux should be left untouched
• subprocess module was added to Python on version 2.4, Django still claim s compatibility with 2.3

Taking in account these issues, patch could be enhanced to check for platform and use either execvp() or call() based on that, but this would leave Windows users using Python 2.3 without a solution, maybe a reasonable tradeoff?.

Also, please unify all the mods in one unified patch.

[markshep]

There are quite a few differences between Python on Windows and Python on POSIX systems. Quite why the Windows porters of Python decided to do things differently is a mystery to me, as I'd have thought that cross-platform consistency would be a goal of any high level language like Python. Anyway we've got to work with the tools we've got, and for those of us unfortunate enough to have to work with Windows that means a whole world of pain :-(.

I wasn't aware that Django needed to work with Python 2.3, but now you've pointed that out I'll try to come up with a fix which works for that. If I find a way of making this work I'll make a single patch which covers all the databases.

[markshep]

OK, I've got a patch which I'll attach now. My first idea was to use os.spawnvp(), but apparently that's only implemented in Python for Unix, not Python for Windows. Which is pretty damn strange if you ask me because all the spawn* functions exist as part of the Windows API: ​http://msdn.microsoft.com/en-us/library/20y988d2(VS.80).aspx. So I've used os.system instead, but only when os.name == 'nt'.

I hope the new patch (db.patch) addresses the problems you raised. If not, please let me know.

[jumpfroggy]

I'm experiencing some problems related to this bug. I filed a DUP bug here (​http://code.djangoproject.com/ticket/10639) with the same symptoms (mysql.exe executing in the background). I tried the db.patch from here, and it does allow me to execute manage.py dbshell and use the mysql client. However, it does not work for manage.py dbshell < data.sql, which is what I really want to do. In that case, the mysql client executes as if it had never seen the < data.sql redirection, and is in interactive mode.

Seems like there's some issue with pipe redirection going on... any ideas why this doesn't work with the above fix?

[jumpfroggy]

Ahh, found the root of my redirection bug. Found here (​http://www.velocityreviews.com/forums/t318845-piping-data-into-python-on-the-command-line-windows-2000.html). The bug is in cmd.exe. So running this fails on windows: manage.py dbshell < data.sql, but running this on windows works python manage.py dbshell < data.sql. Finally, an answer! Stupid windows.

[Malcolm Tredinnick]

(In [10517]) Fixed #10357 -- Fixed the "dbshell" command for Windows users.

[Malcolm Tredinnick]

(In [10518]) [1.0.X] Fixed #10357 -- Fixed the "dbshell" command for Windows users.

Thanks to markshep for the patch.

Backport of r10517 from trunk.

[Jacob]

Milestone 1.1 deleted