Opened 7 years ago

Closed 6 years ago

Last modified 4 years ago

#10357 closed (fixed)

"manage.py dbshell" broken for MySQL on Windows

Reported by: anonymous Owned by: nobody
Component: Core (Management commands) Version: 1.0
Severity: Keywords:
Cc: virtue@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:

Description

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.

Attachments (3)

mysql.patch (1.3 KB) - added by markshep 7 years ago.
sqlite3.patch (793 bytes) - added by markshep 7 years ago.
db.patch (3.4 KB) - added by markshep 7 years ago.

Download all attachments as: .zip

Change History (16)

Changed 7 years ago by markshep

comment:1 Changed 7 years ago by markshep

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

(oops - forgot to login when submitting this!)

I just attached a fix.

Changed 7 years ago by markshep

comment:2 Changed 7 years ago by markshep

  • Has patch set

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

comment:3 Changed 7 years ago by ramiro

  • Patch needs improvement set

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.

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by 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.

Changed 7 years ago by markshep

comment:6 Changed 7 years ago by jacob

  • milestone set to 1.1
  • Triage Stage changed from Unreviewed to Accepted

comment:7 Changed 6 years ago by russellm

  • Component changed from Uncategorized to django-admin.py

comment:8 Changed 6 years ago by 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?

comment:9 Changed 6 years ago by jumpfroggy

  • Cc virtue@… added

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:12 Changed 6 years ago by mtredinnick

(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.

comment:13 Changed 4 years ago by jacob

  • milestone 1.1 deleted

Milestone 1.1 deleted

Note: See TracTickets for help on using tickets.
Back to Top