Opened 14 months ago

Closed 14 months ago

Last modified 14 months ago

#35094 closed New feature (wontfix)

Add pure Python dbshell fallback

Reported by: Jake Howard Owned by: nobody
Component: Core (Management commands) Version: 5.0
Severity: Normal Keywords: sqlite dbshell in-memory
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no
Pull Requests:How to create a pull request

Description

dbshell attempts to shell out to the client tooling for the relevant database engine (sqlite3, psql etc) for dbshell. If the tooling isn't installed, it can't shell. However, for a more naive shell implementation, it would be simple to pipe commands through to connection.cursor().execute and get at least some of the benefit without needing to install the client command-line tooling.

Whilst this wouldn't have the client-side magic (eg backslash commands in Postgres or . commands in sqlite), nor tab complete, it can still be a lot more useful than nothing. An implementation of this shipped in Python 3.12 for SQLite (https://github.com/python/cpython/blob/main/Lib/sqlite3/__main__.py), which can easily be adapted and made generic for all database engines.

Doing this has a side benefit of also giving support for a dbshell for in-memory SQLite connections, which are currently misleading through dbshell, as it doesn't reuse the same connection that Django does, meaning any database bootstrapping done during startup (best-practice aside) is lost. An in-process connection reuses the same connnection, and thus allows access to that in-memory database.

Change History (2)

comment:1 by Mariusz Felisiak, 14 months ago

Component: Database layer (models, ORM)Core (Management commands)
Resolution: wontfix
Status: newclosed
Summary: Add pure Python `dbshell` fallbackAdd pure Python dbshell fallback

Thanks for this ticket, however I don't see much burnout in installing database clients if users want to use database in a shell. It's also not something that needs to be shipped by Django itself. It sounds like a third-party package is the best way to proceed so that people can try it out and then approaching the DevelopersMailingList to reach a wider audience and see what other think.

which can easily be adapted and made generic for all database engines.

I don't think it is, but you may prove that I'm wrong. The devil is in the details.

Doing this has a side benefit of also giving support for a dbshell for in-memory SQLite connections, which are currently misleading through dbshell, as it doesn't reuse the same connection that Django does, meaning any database bootstrapping done during startup (best-practice aside) is lost. An in-process connection reuses the same connnection, and thus allows access to that in-memory database.

I'm not sure how would you like to achieve this, dbshell is a management command. How would you like to share the same in-memory database as e.g. runserver?

comment:2 by Jake Howard, 14 months ago

How would you like to share the same in-memory database as e.g. runserver?

Sadly, you couldn't - but at least it'd make testing any of the bootstrapping during startup easier, and quickly checking any data.

It sounds like a third-party package is the best way to proceed

On reflection, I agree!

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