所以大约一年前我开始了一个项目，和所有新开发人员一样，我并没有真正关注结构，但是现在我与 Django 一起更进一步，它开始出现我的项目布局主要是我的模型在结构上很糟糕.
我的模型主要保存在一个应用程序中，实际上这些模型中的大多数应该在它们自己的单独应用程序中，我确实尝试解决这个问题并将它们向南移动，但是由于外键等，我发现它很棘手而且非常困难。
然而，由于 Django 1.7 并内置了对迁移的支持，现在有更好的方法吗？
问问题
37163 次
11 回答
360
这可以很容易地使用migrations.SeparateDatabaseAndState. 基本上，我们使用数据库操作来重命名表，同时使用两个状态操作从一个应用程序的历史记录中删除模型并在另一个应用程序的历史记录中创建它。
从旧应用程序中删除
python manage.py makemigrations old_app --empty
在迁移中：
class Migration(migrations.Migration):
dependencies = []
database_operations = [
migrations.AlterModelTable('TheModel', 'newapp_themodel')
]
state_operations = [
migrations.DeleteModel('TheModel')
]
operations = [
migrations.SeparateDatabaseAndState(
database_operations=database_operations,
state_operations=state_operations)
]
添加到新应用
首先，将模型复制到新应用的model.py，然后：
python manage.py makemigrations new_app
这将生成一个以幼稚CreateModel操作作为唯一操作的迁移。将其包装在一个SeparateDatabaseAndState操作中，这样我们就不会尝试重新创建表。还包括先前的迁移作为依赖项：
class Migration(migrations.Migration):
dependencies = [
('old_app', 'above_migration')
]
state_operations = [
migrations.CreateModel(
name='TheModel',
fields=[
('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
],
options={
'db_table': 'newapp_themodel',
},
bases=(models.Model,),
)
]
operations = [
migrations.SeparateDatabaseAndState(state_operations=state_operations)
]
于 2014-10-20T18:30:12.180 回答
29
我正在删除旧答案，因为可能会导致数据丢失。正如ozan 提到的，我们可以在每个应用程序中创建 2 个迁移。这篇文章下面的评论是指我的旧答案。
从第一个应用程序中删除模型的第一次迁移。
$ python manage.py makemigrations old_app --empty
编辑迁移文件以包含这些操作。
class Migration(migrations.Migration):
database_operations = [migrations.AlterModelTable('TheModel', 'newapp_themodel')]
state_operations = [migrations.DeleteModel('TheModel')]
operations = [
migrations.SeparateDatabaseAndState(
database_operations=database_operations,
state_operations=state_operations)
]
第二次迁移取决于第一次迁移并在第二个应用程序中创建新表。将模型代码移动到第二个应用程序后
$ python manage.py makemigrations new_app
并将迁移文件编辑为这样的内容。
class Migration(migrations.Migration):
dependencies = [
('old_app', 'above_migration')
]
state_operations = [
migrations.CreateModel(
name='TheModel',
fields=[
('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
],
options={
'db_table': 'newapp_themodel',
},
bases=(models.Model,),
)
]
operations = [
migrations.SeparateDatabaseAndState(state_operations=state_operations)
]
于 2014-09-03T19:13:08.720 回答
28
我遇到了同样的问题。 Ozan 的回答对我帮助很大，但不幸的是还不够。事实上，我有几个 ForeignKey 链接到我想要移动的模型。经过一番头痛后，我找到了解决方案，因此决定将其发布以解决人们的时间问题。
您还需要 2 个步骤：
- 在做任何事情之前，将所有
ForeignKey链接更改TheModel为Integerfield. 然后运行python manage.py makemigrations - 完成 Ozan 的步骤后，重新转换您的外键：放回
ForeignKey(TheModel)而不是IntegerField(). 然后再次进行迁移 (python manage.py makemigrations)。然后您可以迁移，它应该可以工作 (python manage.py migrate)
希望能帮助到你。当然，在尝试生产之前先在本地进行测试，以避免出现意外:)
于 2015-04-14T08:29:37.050 回答
15
我是怎么做到的（在 Django==1.8 上测试，使用 postgres，所以可能也是 1.7）
情况
app1.YourModel
但您希望它转到： app2.YourModel
- 将 YourModel（代码）从 app1 复制到 app2。
将此添加到 app2.YourModel：
Class Meta: db_table = 'app1_yourmodel'$ python manage.py makemigrations app2
使用 migrations.CreateModel() 语句在 app2 中进行新的迁移（例如 0009_auto_something.py），将此语句移动到 app2 的初始迁移（例如 0001_initial.py）（就像它一直存在一样）。现在删除创建的迁移 = 0009_auto_something.py
就像您采取行动一样，就像 app2.YourModel 一直存在一样，现在从您的迁移中删除 app1.YourModel 的存在。含义：注释掉 CreateModel 语句，以及之后您使用的每个调整或数据迁移。
当然，每个对 app1.YourModel 的引用都必须通过您的项目更改为 app2.YourModel。另外，不要忘记迁移中 app1.YourModel 的所有可能外键都必须更改为 app2.YourModel
现在，如果您执行 $ python manage.py migrate，没有任何变化，当您执行 $ python manage.py makemigrations 时，也没有检测到任何新内容。
现在画龙点睛：从 app2.YourModel 中删除 Class Meta 并执行 $ python manage.py makemigrations app2 && python manage.py migrate app2 （如果您查看此迁移，您会看到类似这样的内容：）
migrations.AlterModelTable( name='yourmodel', table=None, ),
table=None，意味着它将采用默认的表名，在本例中为 app2_yourmodel。
- 完成，数据已保存。
PS 在迁移过程中它会看到 content_type app1.yourmodel 已被删除并且可以删除。您可以对此说“是”，但前提是您不使用它。如果您严重依赖它来使该内容类型的 FK 完好无损，请不要回答“是”或“否”，而是手动进入数据库，然后删除内容类型 app2.yourmodel，然后重命名内容类型 app1。 yourmodel 到 app2.yourmodel，然后回答 no 继续。
于 2015-06-11T15:01:45.543 回答
14
我对手工编码迁移感到紧张（正如Ozan 的回答所要求的那样），因此以下结合了 Ozan 和Michael 的策略，以尽量减少所需的手工编码量：
- 在移动任何模型之前，请确保通过运行
makemigrations. - 将模型的代码从移动
app1到app2 db_table正如@Michael 建议的那样，我们使用“新”模型上的 Meta 选项将新模型指向旧数据库表：class Meta: db_table = 'app1_yourmodel'运行
makemigrations。这将生成CreateModelinapp2和DeleteModelinapp1。从技术上讲，这些迁移指的是完全相同的表，并且会删除（包括所有数据）并重新创建表。实际上，我们不想（或不需要）对桌子做任何事情。我们只需要 Django 相信已经做出了改变。根据@Ozan 的回答，
state_operations标志就是SeparateDatabaseAndState这样做的。因此，我们将所有迁移文件migrations中的所有条目都用. 例如，SeparateDatabaseAndState(state_operations=[...])operations = [ ... migrations.DeleteModel( name='YourModel', ), ... ]变成
operations = [ migrations.SeparateDatabaseAndState(state_operations=[ ... migrations.DeleteModel( name='YourModel', ), ... ]) ]您还需要确保新的“虚拟”
CreateModel迁移依赖于实际创建或更改原始表的任何迁移。例如，如果您的新迁移是app2.migrations.0004_auto_<date>(for theCreate) 和app1.migrations.0007_auto_<date>(for theDelete)，最简单的做法是：- 打开
app1.migrations.0007_auto_<date>并复制其app1依赖项（例如('app1', '0006...'),）。这是“紧接在前”的迁移app1，应该包括对所有实际模型构建逻辑的依赖。 - 打开
app2.migrations.0004_auto_<date>并将您刚刚复制的依赖项添加到其dependencies列表中。
- 打开
如果您ForeignKey与要移动的模型有关系，则上述方法可能不起作用。发生这种情况是因为：
ForeignKey不会为更改自动创建依赖项- 我们不想包装
ForeignKey更改，state_operations因此我们需要确保它们与表操作分开。
注意：Django 2.2 添加了一个警告 ( models.E028) 会破坏此方法。您可能可以解决它，managed=False但我尚未对其进行测试。
“最小”操作集因情况而异，但以下过程应适用于大多数/所有ForeignKey迁移：
- 将模型从
app1to复制app2到setdb_table，但不要更改任何 FK 引用。 - 运行
makemigrations并包装所有app2迁移state_operations（见上文）- 如上，在
app2CreateTable到最新的app1迁移中添加一个依赖
- 如上，在
- 将所有 FK 引用指向新模型。如果您不使用字符串引用，请将旧模型移动到
models.py（不要删除它）的底部，这样它就不会与导入的类竞争。 运行
makemigrations但不要包装任何东西state_operations（实际上应该发生 FK 更改）。在所有迁移中添加一个依赖项ForeignKey（即AlterField）到CreateTable迁移中app2（下一步需要此列表，因此请跟踪它们）。例如：- 找到包含
CreateModeleg的迁移app2.migrations.0002_auto_<date>并复制该迁移的名称。 查找具有该模型的 ForeignKey 的所有迁移（例如，通过搜索
app2.YourModel查找迁移，例如：class Migration(migrations.Migration): dependencies = [ ('otherapp', '0001_initial'), ] operations = [ migrations.AlterField( model_name='relatedmodel', name='fieldname', field=models.ForeignKey(... to='app2.YourModel'), ), ]将
CreateModel迁移添加为依赖项：class Migration(migrations.Migration): dependencies = [ ('otherapp', '0001_initial'), ('app2', '0002_auto_<date>'), ]
- 找到包含
从中删除模型
app1- 运行
makemigrations并将app1迁移包装在state_operations.- 将依赖项添加到上一步中的所有
ForeignKey迁移（即AlterField）（可能包括app1和中的迁移app2）。 - 当我构建这些迁移时，它们
DeleteTable已经依赖于AlterField迁移，所以我不需要手动执行它（即AlterbeforeDelete）。
- 将依赖项添加到上一步中的所有
在这一点上，Django 很好。新模型指向旧表，Django 的迁移已经说服它所有内容都已适当地重新定位。最大的警告（来自@Michael 的回答）是ContentType为新模型创建了一个新模型。如果您链接（例如通过ForeignKey）到内容类型，则需要创建迁移以更新ContentType表。
我想自己清理（元选项和表名），所以我使用了以下过程（来自@Michael）：
- 删除
db_table元条目 makemigrations再次运行生成数据库重命名- 编辑最后一次迁移并确保它取决于
DeleteTable迁移。似乎没有必要，因为Delete应该是纯逻辑的，但如果我不这样做，我会遇到错误（例如app1_yourmodel不存在）。
于 2018-02-26T23:16:40.700 回答
3
如果数据不大或太复杂，但维护仍然很重要，另一种 hacky 选择是：
- 使用manage.py dumpdata获取数据夹具
- 继续正确建模更改和迁移，而不关联更改
- 将旧模型和应用程序名称中的固定装置全局替换为新的
- 使用manage.py loaddata加载数据
于 2017-06-20T06:45:07.600 回答
1
复制自我在https://stackoverflow.com/a/47392970/8971048的回答
如果您需要移动模型并且您不再有权访问应用程序（或者您不希望访问），您可以创建一个新的操作并考虑仅在迁移的模型没有的情况下创建一个新模型存在。
在此示例中，我将“MyModel”从 old_app 传递给 myapp。
class MigrateOrCreateTable(migrations.CreateModel):
def __init__(self, source_table, dst_table, *args, **kwargs):
super(MigrateOrCreateTable, self).__init__(*args, **kwargs)
self.source_table = source_table
self.dst_table = dst_table
def database_forwards(self, app_label, schema_editor, from_state, to_state):
table_exists = self.source_table in schema_editor.connection.introspection.table_names()
if table_exists:
with schema_editor.connection.cursor() as cursor:
cursor.execute("RENAME TABLE {} TO {};".format(self.source_table, self.dst_table))
else:
return super(MigrateOrCreateTable, self).database_forwards(app_label, schema_editor, from_state, to_state)
class Migration(migrations.Migration):
dependencies = [
('myapp', '0002_some_migration'),
]
operations = [
MigrateOrCreateTable(
source_table='old_app_mymodel',
dst_table='myapp_mymodel',
name='MyModel',
fields=[
('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
('name', models.CharField(max_length=18))
],
),
]
于 2017-11-20T13:23:03.373 回答
0
这是经过粗略测试的，所以不要忘记备份你的数据库！！！
例如，有两个应用程序：src_app和dst_app，我们要将模型MoveMe从移动src_app到dst_app。
为两个应用创建空迁移：
python manage.py makemigrations --empty src_app
python manage.py makemigrations --empty dst_app
让我们假设，新的迁移是XXX1_src_app_newand XXX1_dst_app_new，previuos top 迁移是XXX0_src_app_oldand XXX0_dst_app_old。
添加一个操作，为MoveMe模型重命名表并将其在 ProjectState 中的 app_label 重命名为XXX1_dst_app_new. 不要忘记添加对XXX0_src_app_old迁移的依赖。产生的XXX1_dst_app_new迁移是：
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import models, migrations
# this operations is almost the same as RenameModel
# https://github.com/django/django/blob/1.7/django/db/migrations/operations/models.py#L104
class MoveModelFromOtherApp(migrations.operations.base.Operation):
def __init__(self, name, old_app_label):
self.name = name
self.old_app_label = old_app_label
def state_forwards(self, app_label, state):
# Get all of the related objects we need to repoint
apps = state.render(skip_cache=True)
model = apps.get_model(self.old_app_label, self.name)
related_objects = model._meta.get_all_related_objects()
related_m2m_objects = model._meta.get_all_related_many_to_many_objects()
# Rename the model
state.models[app_label, self.name.lower()] = state.models.pop(
(self.old_app_label, self.name.lower())
)
state.models[app_label, self.name.lower()].app_label = app_label
for model_state in state.models.values():
try:
i = model_state.bases.index("%s.%s" % (self.old_app_label, self.name.lower()))
model_state.bases = model_state.bases[:i] + ("%s.%s" % (app_label, self.name.lower()),) + model_state.bases[i+1:]
except ValueError:
pass
# Repoint the FKs and M2Ms pointing to us
for related_object in (related_objects + related_m2m_objects):
# Use the new related key for self referential related objects.
if related_object.model == model:
related_key = (app_label, self.name.lower())
else:
related_key = (
related_object.model._meta.app_label,
related_object.model._meta.object_name.lower(),
)
new_fields = []
for name, field in state.models[related_key].fields:
if name == related_object.field.name:
field = field.clone()
field.rel.to = "%s.%s" % (app_label, self.name)
new_fields.append((name, field))
state.models[related_key].fields = new_fields
def database_forwards(self, app_label, schema_editor, from_state, to_state):
old_apps = from_state.render()
new_apps = to_state.render()
old_model = old_apps.get_model(self.old_app_label, self.name)
new_model = new_apps.get_model(app_label, self.name)
if self.allowed_to_migrate(schema_editor.connection.alias, new_model):
# Move the main table
schema_editor.alter_db_table(
new_model,
old_model._meta.db_table,
new_model._meta.db_table,
)
# Alter the fields pointing to us
related_objects = old_model._meta.get_all_related_objects()
related_m2m_objects = old_model._meta.get_all_related_many_to_many_objects()
for related_object in (related_objects + related_m2m_objects):
if related_object.model == old_model:
model = new_model
related_key = (app_label, self.name.lower())
else:
model = related_object.model
related_key = (
related_object.model._meta.app_label,
related_object.model._meta.object_name.lower(),
)
to_field = new_apps.get_model(
*related_key
)._meta.get_field_by_name(related_object.field.name)[0]
schema_editor.alter_field(
model,
related_object.field,
to_field,
)
def database_backwards(self, app_label, schema_editor, from_state, to_state):
self.old_app_label, app_label = app_label, self.old_app_label
self.database_forwards(app_label, schema_editor, from_state, to_state)
app_label, self.old_app_label = self.old_app_label, app_label
def describe(self):
return "Move %s from %s" % (self.name, self.old_app_label)
class Migration(migrations.Migration):
dependencies = [
('dst_app', 'XXX0_dst_app_old'),
('src_app', 'XXX0_src_app_old'),
]
operations = [
MoveModelFromOtherApp('MoveMe', 'src_app'),
]
XXX1_dst_app_new添加对的依赖XXX1_src_app_new。XXX1_src_app_new是无操作迁移，需要确保将来的src_app迁移将在XXX1_dst_app_new.
MoveMe从移动src_app/models.py到dst_app/models.py。然后运行：
python manage.py migrate
就这样！
于 2014-09-12T12:53:49.697 回答
0
您可以尝试以下（未经测试）：
- 将模型从 移动
src_app到dest_app - 迁移
dest_app；确保架构迁移取决于最新的src_app迁移（https://docs.djangoproject.com/en/dev/topics/migrations/#migration-files） - 向 中添加数据迁移
dest_app，将所有数据从src_app - 迁移
src_app；确保架构迁移依赖于最新的（数据）迁移dest_app——即：步骤 3 的迁移
请注意，您将复制整个表格，而不是移动它，但是这样两个应用程序都不必接触属于另一个应用程序的表格，我认为这更重要。
于 2014-10-13T13:18:41.717 回答
0
假设您将模型 TheModel 从 app_a 移动到 app_b。
另一种解决方案是手动更改现有迁移。这个想法是，每次您在 app_a 的迁移中看到更改 TheModel 的操作时，您都会将该操作复制到 app_b 初始迁移的末尾。每次您在 app_a 的迁移中看到引用“app_a.TheModel”时，将其更改为“app_b.TheModel”。
我只是为一个现有项目做了这个，我想将某个模型提取到一个可重用的应用程序中。手续很顺利。我想如果有从 app_b 到 app_a 的引用，事情会变得更加困难。此外，我为我的模型手动定义了一个 Meta.db_table，这可能会有所帮助。
值得注意的是，您最终会改变迁移历史。这无关紧要，即使您有一个应用了原始迁移的数据库。如果原始迁移和重写迁移最终都具有相同的数据库模式，那么这种重写应该是可以的。
于 2015-10-13T07:11:10.857 回答
0
- 将旧模型的名称更改为“model_name_old”</li>
- 移民
- 在相关模型上创建具有相同关系的名为“model_name_new”的新模型（例如，用户模型现在具有 user.blog_old 和 user.blog_new）
- 移民
- 编写自定义迁移，将所有数据迁移到新模型表
- 通过在运行迁移之前和之后将备份与新的数据库副本进行比较来测试这些迁移的地狱
- 当一切都令人满意时，删除旧模型
- 移民
- 将新模型更改为正确的名称 'model_name_new' -> 'model_name'</li>
- 在登台服务器上测试全部迁移
- 将您的生产站点关闭几分钟，以便在没有用户干预的情况下运行所有迁移
为需要移动的每个模型单独执行此操作。我不建议通过更改为整数并返回外键来做其他答案所说的那样有可能新的外键会有所不同，并且迁移后行可能具有不同的 ID，我不想冒任何风险切换回外键时不匹配的 id。
于 2017-04-04T05:25:20.217 回答