2012-05-31 22 views
14

Me estoy moviendo página web django de un servidor a otro, y traté de syncdb, por lo que he puesto python manage.py syncdb, y me da este resultado:Django syncdb y migrar

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) 

El siguiente paso fue python manage.py migrate, y esto es lo que tengo:

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") 

Mi pregunta es qué es necesario para eliminar las tablas django_template y django_template_sites de MySQL? Ambas tablas están vacías.

estoy corriendo en CentOS 6, Django 1.3.1, Python 2.6

Respuesta

1

Otra alternativa es que la primera marca de la migración como se hace:

./manage.py migrate dbtemplates --fake 0001 

Parece ser que ya tiene en su base de datos del esquema que desea crear.

+0

Eso no ayudó, nada ha cambiado. Ejecuto su comando, y de nuevo 'python manage.py syncdb' y la salida es la misma. – miszczu

+0

debería ser "python manage.py migrate --fake [nombre_de_aplicación] 0001" – chenyi1976

6
$python manage.py syncdb --migrate 

este migra lo que tiene que migrar

trabajó para mí (django 1,4)

15

Esto podría ayudar a otras personas que atraviesan la misma edición .

Como su base de datos debe crearse ahora y no se necesitan migraciones, después de hacer lo que Ahmad mencionó, también realice una migración falsa para que south marque todos los scripts de migración como ya se ejecutó. En resumen, ejecuta estos.

syncdb --all 
migrate --fake 

Tenga en cuenta que si ya tiene datos en su base de datos, no debe usar syncdb --all.

+0

syncdb --todo funcionó para mí – Saad

Cuestiones relacionadas