2012-05-31 11 views
14

mi sto muovendo sito Django da un server a un altro, e ho cercato di syncdb, così ho messo python manage.py syncdb, e ottengo questo output:Django SyncDB e migrare

Syncing... 
Creating tables ... 
The following content types are stale and need to be deleted: 

    orders | ordercontact 

Any objects related to these content types by a foreign key will also 
be deleted. Are you sure you want to delete these content types? 
If you're unsure, answer 'no'. 

    Type 'yes' to continue, or 'no' to cancel: no 
Installing custom SQL ... 
Installing indexes ... 
No fixtures found. 

Synced: 
> django.contrib.auth 
> django.contrib.contenttypes 
> django.contrib.sessions 
> django.contrib.sites 
> django.contrib.messages 
> django.contrib.admin 
> django.contrib.admindocs 
> django.contrib.markup 
> django.contrib.sitemaps 
> django.contrib.redirects 
> django_filters 
> freetext 
> sorl.thumbnail 
> django_extensions 
> south 
> currencies 
> pagination 
> tagging 
> honeypot 
> core 
> faq 
> logentry 
> menus 
> news 
> shop 
> shop.cart 
> shop.orders 

Not synced (use migrations): 
- dbtemplates 
- contactform 
- links 
- media 
- pages 
- popularity 
- testimonials 
- shop.brands 
- shop.collections 
- shop.discount 
- shop.pricing 
- shop.product_types 
- shop.products 
- shop.shipping 
- shop.tax 
(use ./manage.py migrate to migrate these) 

Il passo successivo è stato python manage.py migrate, e questo è quello che ho:

Running migrations for dbtemplates: 
- Migrating forwards to 0002_auto__del_unique_template_name. 
> dbtemplates:0001_initial 
! Error found during real run of migration! Aborting. 

! Since you have a database that does not support running 
! schema-altering statements in transactions, we have had 
! to leave it in an interim state between migrations. 

! You *might* be able to recover with: = DROP TABLE `django_template` CASCADE; [] 
    = DROP TABLE `django_template_sites` CASCADE; [] 

! The South developers regret this has happened, and would 
! like to gently persuade you to consider a slightly 
! easier-to-deal-with DBMS. 
! NOTE: The error which caused the migration to fail is further up. 
Traceback (most recent call last): 
    File "manage.py", line 13, in <module> 
    execute_manager(settings) 
    File "/usr/lib/python2.6/site-packages/django/core/management/__init__.py", line 438, in execute_manager 
    utility.execute() 
    File "/usr/lib/python2.6/site-packages/django/core/management/__init__.py", line 379, in execute 
    self.fetch_command(subcommand).run_from_argv(self.argv) 
    File "/usr/lib/python2.6/site-packages/django/core/management/base.py", line 191, in run_from_argv 
    self.execute(*args, **options.__dict__) 
    File "/usr/lib/python2.6/site-packages/django/core/management/base.py", line 220, in execute 
    output = self.handle(*args, **options) 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/management/commands/migrate.py", line 105, in handle 
    ignore_ghosts = ignore_ghosts, 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/migration/__init__.py", line 191, in migrate_app 
    success = migrator.migrate_many(target, workplan, database) 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 221, in migrate_many 
    result = migrator.__class__.migrate_many(migrator, target, migrations, database) 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 292, in migrate_many 
    result = self.migrate(migration, database) 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 125, in migrate 
    result = self.run(migration) 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 99, in run 
    return self.run_migration(migration) 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 81, in run_migration 
    migration_function() 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py", line 57, in <lambda> 
    return (lambda: direction(orm)) 
    File "/usr/lib/python2.6/site-packages/django_dbtemplates-1.3-py2.6.egg/dbtemplates/migrations/0001_initial.py", line 18, in forwards 
    ('last_changed', self.gf('django.db.models.fields.DateTimeField')(default=datetime.datetime.now)), 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/db/generic.py", line 226, in create_table 
    ', '.join([col for col in columns if col]), 
    File "/usr/lib/python2.6/site-packages/South-0.7.3-py2.6.egg/south/db/generic.py", line 150, in execute 
    cursor.execute(sql, params) 
    File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line 34, in execute 
    return self.cursor.execute(sql, params) 
    File "/usr/lib/python2.6/site-packages/django/db/backends/mysql/base.py", line 86, in execute 
    return self.cursor.execute(query, args) 
    File "/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py", line 174, in execute 
    self.errorhandler(self, exc, value) 
    File "/usr/lib64/python2.6/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler 
    raise errorclass, errorvalue 
_mysql_exceptions.OperationalError: (1050, "Table 'django_template' already exists") 

la mia domanda è ho bisogno di rimuovere le tabelle django_template e django_template_sites da MySQL? Entrambi i tavoli sono vuoti.

Io corro su CentOS 6, Django 1.3.1, Python 2.6

risposta

1

Un'altra alternativa è segno che prima migrazione come fatto:

./manage.py migrate dbtemplates --fake 0001 

Sembra essere che già avete nella vostra database lo schema che si desidera creare.

+0

Questo non ha aiutato, non è cambiato nulla. Eseguo il tuo comando, e di nuovo 'python manage.py syncdb' e l'output è lo stesso. – miszczu

+0

dovrebbe essere "python manage.py migrate --fake [nome app] 0001" – chenyi1976

6
$python manage.py syncdb --migrate 

questo migra ciò che deve essere migrato

ha lavorato per me (Django 1,4)

15

Questo potrebbe aiutare gli altri a passare attraverso lo stesso problema .

Poiché il database deve essere creato ora e non sono necessarie migrazioni, dopo aver eseguito ciò che ha menzionato Ahmad, eseguire anche una migrazione fittizia, in modo che a sud vengano contrassegnati tutti gli script di migrazione già eseguiti. In breve, esegui questi.

syncdb --all 
migrate --fake 

Si noti che se si dispone già di dati nel database non è necessario utilizzare syncdb --all.

+0

syncdb - tutto ha funzionato per me – Saad

Problemi correlati