How do I manage a Non-default Django database

Question

I am having trouble using my non-default database in my Django (v1.8) app. When I try makemigrations and migrate the PostgreSQL database does not get updated.

Here is my Django structure:

fbrDjangoSite
|-- db.sqlite3
|-- manage.py
|-- fbrDjangoSite
|   |-- __init__.py
|   |-- requirements.txt
|   |-- settings.py
|   |-- urls.py
|   |-- wsgi.py
|-- fbrPostHasteAppV0_1
|   |-- __init__.py
|   |-- admin.py
|   |-- migrations
|   |-- models.py
|   |-- router.py
|   |-- tests.py
|   |-- urls.py
|   |-- views.py

fbrPostHasteAppV0_1/admin.py

from django.contrib import admin
from fbrPostHasteAppV0_1.models import MusicianTable   # gvim ../fbrPostHasteAppV0_1/models.py +/MusicianTable
from fbrPostHasteAppV0_1.models import AlbumTable      # gvim ../fbrPostHasteAppV0_1/models.py +/AlbumTable

# Register your models here.
admin.site.register(MusicianTable)
admin.site.register(AlbumTable)

fbrPostHasteAppV0_1/models.py

from django.db import models

# Define your models/tables here.
class MusicianTable(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)
    instrument = models.CharField(max_length=100)

    class Meta:
        managed = True

class AlbumTable(models.Model):
    artist = models.ForeignKey(MusicianTable)
    name = models.CharField(max_length=100)
    release_date = models.DateField()
    num_stars = models.IntegerField()

    class Meta:
        managed = True

fbrPostHasteAppV0_1/router.py

class fbrPostHasteAppV0_1Router(object):
    def db_for_read(self, model, **hints):
        if model._meta.app_label == 'fbrPostHasteAppV0_1':
            return 'fbrPostHasteDbV0_1'
        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == 'fbrPostHasteAppV0_1':
            return 'fbrPostHasteDbV0_1'
        return None

    def allow_syncdb(self, db, model):
        if db == 'fbrPostHasteDbV0_1':
            return model._meta.app_label == 'fbrPostHasteAppV0_1'
        elif model._meta.app_label == 'fbrPostHasteAppV0_1':
            return False
        return None

fbrDjangoSite/settings.py

# ...
INSTALLED_APPS = (
    # ...
    'fbrPostHasteAppV0_1',             # v ../fbrPostHasteAppV0_1/__init__.py
)

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    },
    # ...
    'fbrPostHasteDb': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'fbrPostHasteDbV0_1',
        'USER': 'myuser',
        'PASSWORD': '',
        'HOST': 'myhost.us.overlord.com',
        'PORT': '0000',
    },
}

DATABASE_ROUTERS = ['fbrPostHasteAppV0_1.router.fbrPostHasteAppV0_1Router',]

Here is the output when I run the migration commands:

[fbrDjangoServerV0_1.venv.py] /<3>django/fbrDjangoServerV0_1.venv.py/fbrDjangoSite> python manage.py makemigrations fbrPostHasteAppV0_1 --verbosity 3
    /fobar-tools/pylibs/lib/python/Django-1.8-py2.7.egg/django/db/models/base.py:1497: RemovedInDjango19Warning: Router.allow_syncdb has been deprecated and will stop working in Django 1.9. Rename the method to allow_migrate.
      if not router.allow_migrate(db, cls):
    Did you rename the fbrPostHasteAppV0_1.Musician model to MusicianTable? [y/N] y
    Migrations for 'fbrPostHasteAppV0_1':
      0002_auto_20150408_1653.py:
        - Create model AlbumTable
        - Rename model Musician to MusicianTable
        - Remove field artist from album
        - Delete model Album
        - Add field artist to albumtable
[fbrDjangoServerV0_1.venv.py] /<3>django/fbrDjangoServerV0_1.venv.py/fbrDjangoSite> python manage.py migrate --verbosity 3 
    /fobar-tools/pylibs/lib/python/Django-1.8-py2.7.egg/django/db/models/base.py:1497: RemovedInDjango19Warning: Router.allow_syncdb has been deprecated and will stop working in Django 1.9. Rename the method to allow_migrate.
      if not router.allow_migrate(db, cls):
    Operations to perform:
      Synchronize unmigrated apps: staticfiles, messages
      Apply all migrations: fbrSimDataV0_2, sessions, admin, polls, auth, contenttypes, fbrPostHasteAppV0_1
    Synchronizing apps without migrations:
    /fobar-tools/pylibs/lib/python/Django-1.8-py2.7.egg/django/db/utils.py:336: RemovedInDjango19Warning: Router.allow_syncdb has been deprecated and will stop working in Django 1.9. Rename the method to allow_migrate.
      return [model for model in models if self.allow_migrate(db, model)]
      Creating tables...
      Installing custom SQL...
      Installing indexes...
    Running migrations:
      Applying fbrPostHasteAppV0_1.0002_auto_20150408_1653.../fobar-tools/pylibs/lib/python/Django-1.8-py2.7.egg/django/db/migrations/operations/base.py:107: RemovedInDjango19Warning: Router.allow_syncdb has been deprecated and will stop working in Django 1.9. Rename the method to allow_migrate.
      router.allow_migrate(connection_alias, model) and
     OK
    /fobar-tools/pylibs/lib/python/Django-1.8-py2.7.egg/django/contrib/auth/management/__init__.py:70: RemovedInDjango19Warning: Router.allow_syncdb has been deprecated and will stop working in Django 1.9. Rename the method to allow_migrate.
      if not router.allow_migrate(using, Permission):
    The following content types are stale and need to be deleted:
        fbrPostHasteAppV0_1 | album
        fbrPostHasteAppV0_1 | musician

But when I look at the dtatbase the "table" has not been added.

[fbrDjangoServerV0_1.venv.py] /<3>django/fbrDjangoServerV0_1.venv.py/fbrDjangoSite>       psql -h localhost -p 0000 --command "\l" postgres
                                 List of databases
       Name    |  Owner   | Encoding  | Collate | Ctype |   Access privileges
    -----------+----------+-----------+---------+-------+-----------------------
     postgres  | myuser   | SQL_ASCII | C       | C     |
     template0 | myuser   | SQL_ASCII | C       | C     | =c/myuser          +
               |          |           |         |       | myuser=CTc/myuser
     template1 | myuser   | SQL_ASCII | C       | C     | =c/myuser          +
               |          |           |         |       | myuser=CTc/myuser
     test      | myuser   | SQL_ASCII | C       | C     |
    (4 rows)

I was under the impression that Django could create the table and keep it in sync whenever I made changes to the model. Is my understanding correct and if so what am I doing wrong here?

UPDATE

One of my issues is that my router code was based on and older version of Django. I am not sure if this is exactly correct now but it closely resembles the documentation now: https://docs.djangoproject.com/en/1.8/topics/db/multi-db/

class fbrPostHasteAppV0_1Router(object):
    def db_for_read(self, model, **hints):
        if model._meta.app_label == 'fbrPostHasteAppV0_1':
            return 'fbrPostHasteDbV0_1'
        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == 'fbrPostHasteAppV0_1':
            return 'fbrPostHasteDbV0_1'
        return None

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

    def allow_migrate(self, db, app_label, model=None, **hints):
        if app_label == 'fbrPostHasteAppV0_1':
            return db == 'fbrPostHasteDbV0_1'
        return None

The other issue is that I was not calling migrate with --database:

 python manage.py migrate --database=fbrPostHasteDb

But now I am getting another error:

django.db.utils.OperationalError: FATAL:  database "fbrPostHasteDbV0_1" does not exist

Continuing to figure out what else I messed up...

UPDATE 2

So I created the database like this:

psql -h localhost -p 8080 --command "CREATE DATABASE fbrPostHasteDbV0_1"

But it created fbrposthastedbv0_1 instead.

So Once I changed all the references and the names I was able to:

python manage.py migrate --database=fbrPostHasteDb

Answer 1

You're going to have to manually change the necessary fields, I'm not sure of the exact postgres bugs but I dealt with a similar situation a month ago. Migrations are a pain at times, but after fixing them report to:

https://docs.djangoproject.com/en/1.8/internals/contributing/bugs-and-features/