Opened 7 years ago

Closed 3 years ago

#6338 closed New feature (duplicate)

Better error message on sqlite3 failure

Reported by: simeon Owned by: simeon
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: yes UI/UX: no

Description

I recently updgraded my OS and restored my django projects from backup. The django shell worked but when I ran manage.py dbshell
I got a exception ending in

  File "/usr/lib/python2.5/site-packages/django/db/__init__.py", line 48, in <lambda>
    runshell = lambda: _import_database_module(_import_path, "client").runshell()
  File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/client.py", line 6, in runshell
    os.execvp('sqlite3', args)
  File "/usr/lib/python2.5/os.py", line 354, in execvp
    _execvpe(file, args)
  File "/usr/lib/python2.5/os.py", line 392, in _execvpe
    func(fullname, *argrest)
OSError: [Errno 2] No such file or directory

The astute pythoner notes the 3rd line up tries to execute a call to sqlite3 and the actual error message "No such file or directory" is just to indicate that we couldn't execute the sqlite3 binary. It took me a minute to realise that I hadn't yet installed sqlite3 and I was on my way. Should we catch the exception and provide a more explicit error message? See patch - but I don't mind if this is a wontfix.

Attachments (2)

patch.diff (704 bytes) - added by simeon 7 years ago.
patch.2.diff (1.5 KB) - added by aashu_dwivedi 3 years ago.
patches the same in /django/core/management/command.py

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by simeon

comment:1 Changed 7 years ago by Simon Greenhill <dev@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Ready for checkin

comment:2 Changed 7 years ago by mtredinnick

  • Patch needs improvement set
  • Triage Stage changed from Ready for checkin to Accepted

Surely the same problem must exist with all the other backends as well. So let's fix the problem, not just one arm of the problem (i.e. patch them all).

With regards to the patch, a few changes I'd like to see:

  1. Error messages that are only going to be seen by a developer don't get marked for translation. That saves on the workload for translators a bit.
  2. Use errno.ENOENT rather than the magic number "2" in the error check. It's more self-descriptive that way.
  3. The final bare "except" is unneeded. Uncaught exceptions are always raised out of the local block.

comment:3 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to New feature

Technically a new feature. Not sure how current this is now though...

comment:4 Changed 4 years ago by ptone

  • Easy pickings set
  • UI/UX unset

Changed 3 years ago by aashu_dwivedi

patches the same in /django/core/management/command.py

comment:5 Changed 3 years ago by aashu_dwivedi

Its already covered in /django/core/management/command.py under the following code

  def handle(self, **options):
        connection = connections[options.get('database', DEFAULT_DB_ALIAS)]
        try:
            connection.client.runshell()
        except OSError:
            # Note that we're assuming OSError means that the client program                                                                                 
            # isn't installed. There's a possibility OSError would be raised                                                                                 
            # for some other reason, in which case this error message would be                                                                               
            # inaccurate. Still, this message catches the common case.                                                                                       
            raise CommandError('You appear not to have the %r program installed or on your path.' % \
                connection.client.executable_name)

If more specific error handling is required as in simeon's patch and as pointed out by mtredinnkick I have included a patch for the same which displays the error only if the executable is not found else raises the exception for user to figure out what is wrong .

comment:6 Changed 3 years ago by claudep

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

As aashu_dwivedi wrote, this is now properly handled in command.py (fixed in r8990 / #8978). I don't see any real use case where patch.2.diff would be useful, but I suggest creating a new ticket if this is the case.

Closing as dup of #8978

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