Opened 13 years ago
Closed 13 years ago
#17898 closed Bug (fixed)
The database option is not honored when `createsuperuser` is called by `syncdb`
| Reported by: | Simon Charette | Owned by: | nobody |
|---|---|---|---|
| Component: | contrib.auth | Version: | 1.3 |
| Severity: | Release blocker | Keywords: | syncdb createsuperuser database multidb |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | yes | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
When calling the syncdb command with a database kwarg
./manage.py syncdb --database my_specific_db
The post_sync_db signal is dispatched correctly but the django.contrib.auth.management.create_superuser receiver doesn't take the db kwarg into account when calling createsuperuser thus it attempts to create it on the default database. It should call the command on the database specified in syncdb.
I'm attaching a patch but I really don't know where I should add tests for this, I can't find where syncdb is tested. Is it??
Attachments (1)
Change History (4)
by , 13 years ago
| Attachment: | syncdb-multidb-createsuperuser.diff added |
|---|
comment:1 by , 13 years ago
| Needs tests: | set |
|---|---|
| Severity: | Normal → Release blocker |
comment:2 by , 13 years ago
I can confirm r17665 introduced the regression.
Everything worked just fine before this changeset since I was using a router to specify the User's db_for_(write|read). Now that using(database) is explicitly called in the createsuperuser command it's not asking the router anymore therefore triggering this issue.
I haven't verified the issue yet, but this could potentially be a bug in a new feature (added in [17665]), therefore marking as release blocker.