2012-05-31 2 views
14

내가 한 서버에서 다른 서버로 장고 웹 사이트를 이동하고있어, 나는 syncdb하려고, 그래서 난 python manage.py syncdb을 넣어했습니다, 그리고 내가이 출력을 얻을 마이그레이션 :장고 syncdb 및

다음 단계는 python manage.py migrate했다
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) 

, 이것은 내가있어 무엇 :

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

내 질문은 내가 MySQL의에서 테이블 django_templatedjango_template_sites을 제거해야합니까입니까? 두 테이블 모두 비어 있습니다. 내가 CentOS는 6, 장고 1.3.1, 파이썬 2.6

답변

1

또 다른 대안에 실행 해요

완료로 첫번째 마이그레이션이 있다는 표시입니다 :

./manage.py migrate dbtemplates --fake 0001 

당신이 이미 가지고 것 같다 당신의 데이터베이스 작성하려는 스키마. 나는이 같은 문제를 가지고 --all 그냥 작품으로

+0

그건 도움이되지 않았지만 아무것도 변경되지 않았습니다. 나는 당신의 명령을 실행하고, 다시'python manage.py syncdb'와 출력은 같습니다. – miszczu

+0

은 "python manage.py migrate --fake [app_name] 0001"이어야합니다. – chenyi1976

6
$python manage.py syncdb --migrate 

이 같은 문제를 겪고 다른 사람을 도울 수

15

(1.4 장고) 나를 위해 일한 마이그레이션 할 무슨 마이그레이션 발견 .

데이터베이스가 생성되고 마이그레이션이 필요 없기 때문에 Ahmad가 언급 한대로 가짜 마이그레이션을 수행하면 south가 모든 마이그레이션 스크립트를 이미 실행 된 것으로 표시합니다. 즉, 이들을 실행하십시오.

syncdb --all 
migrate --fake 

데이터베이스에 이미 데이터가있는 경우 syncdb --all을 사용하지 마십시오.

+0

syncdb - 전체적으로 작동합니다. – Saad