[Django] #29564: Executing createsuperuser with non-default database.

16 views
Skip to first unread message

Django

unread,
Jul 14, 2018, 6:23:40 PM7/14/18
to django-...@googlegroups.com
#29564: Executing createsuperuser with non-default database.
-------------------------------------+-------------------------------------
Reporter: Oleg Żero | Owner: nobody
Type: | Status: new
Uncategorized |
Component: | Version: 2.0
Migrations | Keywords: multiple database
Severity: Normal | router createsuperuser
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Hello!

I tried to use a different, non-default designated database for storing
(auth, admin, contenttype, session), named 'users', another one for that
is application-specific 'application' and 'default' is then used for
everything else, like this:


{{{
...
DATABASES = {
'default': dj_database_url.parse(os.environ['DATABASE_OPS_URL'],
conn_max_age=500), # for everything else...
'users': dj_database_url.parse(os.environ['DATABASE_USR_URL'],
conn_max_age=500), # for auth-stuff
'application': dj_database_url.parse(os.environ['DATABSE_APP_URL'],
conn_max_age=500), # for app
}
DATABASE_ROUTERS = ['myapplication.routers.AuthRouter']
}}}

Following your example [https://docs.djangoproject.com/en/2.0/topics/db
/multi-db/#topics-db-multi-db-routing],
I created a router.py, in which I replicated your code.

Then:
{{{
$ ./manage.py migrate
$ ./manage.py migrate --database=users
$ ./manage.py migrate --database=application
}}}
Works fine. I verified the database content, and yes, the tables are
created in 'users'.

However, when executing:
{{{
$ ./manage.py createsuperuser
}}}
I get prompted to define the name, but just after I hit enter, I get a
django.db.utils.ProgrammingError: relation "auth_user" does not exist
LINE 1: ...user"."is_active", "auth_user"."date_joined" FROM "auth_user...

...and django fails to initialize that user.
The only way I can get it to work, is when the 'users' database matches
the 'default' one.
How do I work around it? Is it a bug?

Thank you very much in advance!

--
Ticket URL: <https://code.djangoproject.com/ticket/29564>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Jul 14, 2018, 6:27:04 PM7/14/18
to django-...@googlegroups.com
#29564: Executing createsuperuser with non-default database.
-------------------------------------+-------------------------------------
Reporter: Oleg Żero | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 2.0
Severity: Normal | Resolution:
Keywords: multiple database | Triage Stage:
router createsuperuser | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Oleg Żero:

Old description:

New description:

Hello!

I tried to use a different, non-default designated database for storing
(auth, admin, contenttype, session), named 'users', another one for that
is application-specific 'application' and 'default' is then used for
everything else, like this:


{{{
...
DATABASES = {
'default': dj_database_url.parse(os.environ['DATABASE_OPS_URL'],
conn_max_age=500), # for everything else...
'users': dj_database_url.parse(os.environ['DATABASE_USR_URL'],
conn_max_age=500), # for auth-stuff
'application': dj_database_url.parse(os.environ['DATABSE_APP_URL'],
conn_max_age=500), # for app
}
DATABASE_ROUTERS = ['myapplication.routers.AuthRouter']

...
}}}

Following your example [https://docs.djangoproject.com/en/2.0/topics/db
/multi-db/#topics-db-multi-db-routing],
I created a router.py, in which I replicated your code.

However, being aware of the cross-database problem, my routers.py looks
like this:
{{{
class AuthRouter(object):
auth_related = (
'auth',
'admin',
'contenttypes',
'sessions',
)

def db_for_read(self, model, **hints):
if model._meta.app_label in self.auth_related:
return 'users'
return None

def db_for_write(self, model, **hints):
if model._meta.app_label in self.auth_related:
return 'users'
return None

def allow_relation(self, obj1, obj2, **hints):
if obj1._meta.app_label in self.auth_related or \
obj2._meta.app_label in self.auth_related:
return True
return None

def allow_migrate(self, db, app_label, model_name=None, **hints):
if app_label in self.auth_related:
return db == 'users'
return None
}}}

Then:
{{{
$ ./manage.py migrate
$ ./manage.py migrate --database=users
$ ./manage.py migrate --database=application
}}}
Works fine. I verified the database content, and yes, the tables are
created in 'users'.

However, when executing:
{{{
$ ./manage.py createsuperuser
}}}
I get prompted to define the name, but just after I hit enter, I get a
django.db.utils.ProgrammingError: relation "auth_user" does not exist
LINE 1: ...user"."is_active", "auth_user"."date_joined" FROM "auth_user...

...and django fails to initialize that user.
The only way I can get it to work, is when the 'users' database matches
the 'default' one.
How do I work around it? Is it a bug?

Thank you very much in advance!

--

--
Ticket URL: <https://code.djangoproject.com/ticket/29564#comment:1>

Django

unread,
Jul 14, 2018, 8:02:39 PM7/14/18
to django-...@googlegroups.com
#29564: Executing createsuperuser with non-default database.
-------------------------------------+-------------------------------------
Reporter: Oleg Żero | Owner: nobody
Type: Bug | Status: closed
Component: contrib.auth | Version: 2.0
Severity: Normal | Resolution: invalid

Keywords: multiple database | Triage Stage:
router createsuperuser | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):

* status: new => closed
* resolution: => invalid
* component: Migrations => contrib.auth
* type: Uncategorized => Bug


Comment:

`createsuperuser` takes a `--database` option just like `migrate`. In the
future, please see TicketClosingReasons/UseSupportChannels to find places
to get help until you confirm a bug.

--
Ticket URL: <https://code.djangoproject.com/ticket/29564#comment:2>

Django

unread,
Sep 22, 2022, 8:43:30 PM9/22/22
to django-...@googlegroups.com
#29564: Executing createsuperuser with non-default database.
-------------------------------------+-------------------------------------
Reporter: Oleg Żero | Owner: nobody
Type: Bug | Status: closed
Component: contrib.auth | Version: 2.0
Severity: Normal | Resolution: invalid
Keywords: multiple database | Triage Stage:
router createsuperuser | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by David A):

I know I'm going to upset someone for posting on a 4yr old topic. but
this is more a documentation bug, but I've long since learned that django
docs are lacking...

--
Ticket URL: <https://code.djangoproject.com/ticket/29564#comment:3>

Django

unread,
Sep 22, 2022, 9:30:15 PM9/22/22
to django-...@googlegroups.com
#29564: Executing createsuperuser with non-default database.
-------------------------------------+-------------------------------------
Reporter: Oleg Żero | Owner: nobody
Type: Bug | Status: closed
Component: contrib.auth | Version: 2.0
Severity: Normal | Resolution: invalid
Keywords: multiple database | Triage Stage:
router createsuperuser | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Tim Graham):

What's the bug? `createsuperuser --database` is
[https://docs.djangoproject.com/en/dev/ref/django-admin/#cmdoption-
createsuperuser-database documented].

--
Ticket URL: <https://code.djangoproject.com/ticket/29564#comment:4>

Reply all
Reply to author
Forward
0 new messages