syncdb does not use SESSION_DB_ALIAS for creating session table

[rokclimb15]

When trying to store sessions in another database using SESSION_DB_ALIAS, syncdb attempts to create the table under the default db alias. It also attempts to connect with the user credentials from the default alias. This is an issue if that user doesn't have create permissions on that database. It seems like it should use the correct alias and user settings from that alias. If you use --database argument with syncdb, it syncs all models to that database, so it doesn't really apply.

I suppose this isn't a tremendous problem since the output from a sql management command can be piped into the database, but it could be confusing because syncdb by default puts the table in the default database and then session will get an error when it tries to access it in the other db (and it doesn't exist).

Example:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'db1',
        'USER': 'dbuser1',                      # Not used with sqlite3.
        'PASSWORD': 'password1',                  # Not used with sqlite3.
        'HOST': '',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    },
    'session': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'session',                      # Or path to database file if using sqlite3.
        'USER': 'dbuser2',                      # Not used with sqlite3.
        'PASSWORD': 'password2',                  # Not used with sqlite3.
        'HOST': '',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

SESSION_DB_ALIAS = 'session'

[Ramiro Morales]

Actually, the multiple-db ​documentation states The syncdb management command operates on one database at a time.

IMHO handling the special case of having the Sessions app use a DB different from the default one and getting syncdb to adapt to it isn't worth breaking the well defined behavior of syncdb touching only one database per invocation.

I propose this ticket component be changed to Documentation and invite people using that particular setup to contribute from their experiences by submitting a patch for the Sessions docs describing the flow than needs to be followed to get things working with the current tools be it either a) a guide of careful steps of adding/removing of django.contrib.sessions from INSTALLED_APPS plus SESSION_DB_ALIAS and syncdb invocations and/or b) by using q ​database router. Even better it seems to me it would be very good real-world example for the Database routers functionality.

I'm not removing the 1.2 milestone until another triager can take a look at this.

[Russell Keith-Magee]

This looks like a collision of pre and post-router behaviour.

SESSION_DB_ALIAS was introduced before the introduction of routers; at that time, it was up to the developer to manually control the syncdb process.

When routers were added, the routing process took control of syncdb. Routers also took control of the decision over which database should be used for read/write operations -- a job previously performed by SESSION_DB_ALIAS.

The fix from Django's point of view is that SESSION_DB_ALIAS should be removed entirely; the fix from the point of view of @rokclimb15 is to implement a router that directs all activity for the sessions app to his sessions database.

[Russell Keith-Magee]

(In [12844]) Fixed #13200 -- Updated the DB session backend to make full use of routers, deprecating the need for the SESSION_DB_ALIAS setting. Thanks to rokclimb15 for the report.

[Jacob]

Milestone 1.2 deleted