Djangoのsyncdbの実行と私は別のサーバーからDjangoのウェブサイトを動かすんだ、と私はsyncdbの実行しようとしたので、私は<code>python manage.py syncdb</code>を入れている、と私はこの出力を得る

Question

を移行：

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) 

次のステップは、python manage.py migrateましたこれは私が持っているものです：

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_templateとdjango_template_sitesを削除する必要がありますか？どちらの表も空です。

私は別の方法としては、最初の移行が行われるようにすることをマークであるパイソン、CentOSの6、ジャンゴ1.3.1に2.6

Answer 1

私は同じ問題を抱えているとだけで動作--allとして

syncdb --all 

を試してみてください。

私はここで、このソリューションは、https://github.com/divio/django-cms/issues/1343

Answer 2

を実行している：

./manage.py migrate dbtemplates --fake 0001 

あなたがすでにあなたの中に持っていることのようですデータベース作成するスキーマ。

Answer 3

$python manage.py syncdb --migrate 

これは

これは、同じ問題を通過する他の人を助けるかもしれない

Answer 4

（1.4ジャンゴ）私のために働い移行する必要があるものを移動しました。

あなたのデータベースは今作成されており、必要な移行がないので、Ahmadが述べたことを実行した後、偽の移行も実行するので、southはすべての移行スクリプトをすでに実行済みとマークするようにします。つまり、これらを実行します。

syncdb --all 
migrate --fake 

データベースに既にデータがある場合は、syncdb --allを使用しないでください。