5
Ich habe Probleme bei der Verwendung meiner nicht standardmäßigen Datenbank in meiner Django (v1.8) -App. Wenn ich versuche Makemigrationen und Migration der PostgreSQL-Datenbank wird nicht aktualisiert.Wie verwalte ich eine nicht standardmäßige Django-Datenbank
Hier ist meine Django Struktur:
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',]
Hier ist die Ausgabe, wenn ich die Migration Befehle ausführen:
[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
Aber wenn ich an der dtatbase schauen die "table" wurde nicht hinzugefügt.
[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)
Ich hatte den Eindruck, dass Django den Tisch schaffen könnte und in synchron halten, wenn ich Änderungen an dem Modell vorgenommen. Ist mein Verständnis korrekt und wenn so was mache ich hier falsch?
UPDATE
Eines meiner Probleme ist, dass Code mein Router basiert auf und ältere Version von Django. Ich bin nicht sicher, ob dies jetzt genau richtig ist, aber es ähnelt die Dokumentation jetzt: 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
Das andere Problem ist, dass ich nicht mit --database migrieren Aufruf:
python manage.py migrate --database=fbrPostHasteDb
Aber jetzt bekomme ich einen anderen Fehler:
django.db.utils.OperationalError: FATAL: database "fbrPostHasteDbV0_1" does not exist
, um herauszufinden, fort, was ich sonst noch vermasselt ...
UPDATE 2
Also habe ich die Datenbank wie folgt aus:
psql -h localhost -p 8080 --command "CREATE DATABASE fbrPostHasteDbV0_1"
Aber es erstellt fbrposthastedbv0_1 statt.
So Einmal änderte ich alle Verweise und die Namen konnte ich:
python manage.py migrate --database=fbrPostHasteDb
$ ./manage.py migrieren --database = fbrPostHasteDb, kann ich dein debug bekommen? Es kann sein, dass das Ändern bestimmter Felder in Postgres Sie auch manuell tun muss. Ich musste vor einem Monat ein varchar-Feld in ein Textfeld ändern und sah, dass Migrationen sich nicht auf die Spalte auswirkten, also musste ich dies manuell tun. – Mikeec3
Es ist da oben. Ein wenig schwer zu sehen, zweiter Code-Schnipsel von unten etwa 1/3 nach unten das Schnipsel. Was ich hier zeige, ist ein ALTER, aber ich hatte den Tisch ursprünglich nicht in psql, also erwartete ich, dass es ein CREATE macht, aber das tat es nicht. – stephenmm