Opened 6 years ago
Closed 5 years ago
#29501 closed New feature (fixed)
Add support for ./manage.py dbshell -c SQL
Reported by: | Artem Skoretskiy | Owned by: | Adam Johnson |
---|---|---|---|
Component: | Core (Management commands) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | tonn81@…, Zijian He | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
At the moment you cannot run specific SQL directly with dbshell
:
./manage.py dbshell -c "select * from auth_group"
You have to use pipes, that are not always convenient:
echo "select * from auth_group" | ./manage.py dbshell
If we add -c
argument, it would be in sync with shell
command, where you could provide commands already.
Change History (22)
comment:1 by , 6 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Version: | 2.0 → master |
comment:2 by , 6 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 6 years ago
Owner: | changed from | to
---|
comment:4 by , 6 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:5 by , 6 years ago
It should be easy to implement since we don’t need to use database-specific backend
Something like that:
from django.db import connection if command: cursor = connection.cursor() cursor.execute(command) # show `cursor.fetchall()` result
comment:6 by , 6 years ago
any progress on this one? Is the previously suggested approach good enough? If so, I'd love to give a try?
comment:7 by , 6 years ago
No progress AKAIK.
Maybe it would be easier to call database-specific CLI tool with right parameters than run cursor.
Pros:
- No need to care about printing results (user could execute SELECT)
- Could run commands that are unique for the CLI (e.g. \dt to show tables in psql)
Cons:
- Each backend would need its own command to run (but we already have dbshell, so we know name of binary; just need a parameter to execute a query).
- Each backend would show results in its own format, so you cannot e. g. save result as cab file)
Another completely different approach would be to pass all command line arguments provided to dbshell, e.g. after “—“ divider to database CLI app. For example:
./manage.py dbshell — -c “select * from auth_user”
comment:8 by , 6 years ago
I don't think opening a cursor is the right way. My mental model of dbshell is that it always passes through to the underlying tool, which can have subtle implications on even what SQL/commands are accepted.
I am actually most in favour of passing all arguments through after a --
divider as that is the most flexible.
comment:9 by , 6 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:10 by , 6 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
Needs tests: | set |
Triage Stage: | Accepted → Ready for checkin |
comment:11 by , 6 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
"Ready for checkin" is set by a patch reviewer. And the patch isn't ready for review without tests and documentation.
comment:12 by , 5 years ago
So the PR is closed due to missing Tests and Documentation. Does anybody care that I take this?
I could make a PR based on the original one and add tests and docs
comment:13 by , 5 years ago
Absolutely, feel free to work on issues obviously stalled. Just credit original patch writers if appropriate.
comment:14 by , 5 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Owner: | changed from | to
comment:15 by , 5 years ago
Patch needs improvement: | set |
---|
comment:16 by , 5 years ago
Patch needs improvement: | unset |
---|
comment:17 by , 5 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
This seems reasonable, at first glance at least. The trick will be to pass the command to each of the backend clients correctly, but there's no reason that's not possible right? Accepting on that basis. A PR is very welcome.