blocks|key|1481379|text|模型与应用程序的耦合不是很紧密，所以移动起来相当简单。Django在数据库表的名称中使用应用程序名称，所以如果你想移动你的应用程序，你可以通过SQL+ALTER+TABLE语句重命名数据库表，或者--更简单--只需在模型的Meta类中使用db_table+parameter来引用旧名称。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1481380|如果到目前为止，您已经在代码中的任何地方使用了ContentTypes或泛型关系，那么您可能希望重命名指向正在移动的模型的contenttype的app_label，以便保留现有的关系。|1481381|当然，如果您根本没有要保留的数据，最简单的做法是完全删除数据库表，然后再次运行./manage.py+syncdb。|1481382|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.djangoproject.com/en/dev/ref/models/options/#db-table^0|23|B|33|4|3B|8|3B|I|0|0|21|9|0|13|I|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@$9|Y|A|Z|1|10]]|E|$]]|$1|F|3|G|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

<p>Models aren't very tightly coupled to apps, so moving is fairly simple. Django uses the app name in the name of the database table, so if you want to move your app you can either rename the database table via an SQL <code>ALTER TABLE</code> statement, or - even simpler - just use the <a href="http://docs.djangoproject.com/en/dev/ref/models/options/#db-table" rel="noreferrer"><code>db_table</code> parameter</a> in your model's <code>Meta</code> class to refer to the old name.</p>

<p>If you've used ContentTypes or generic relations anywhere in your code so far, you will probably want to rename the <code>app_label</code> of the contenttype pointing at the model that's moving, so that existing relations are preserved.</p>

<p>Of course, if you don't have any data at all to preserve, the easiest thing to do is to drop the database tables completely and run <code>./manage.py syncdb</code> again.</p>


blocks|key|1481424|text|因此，在South+0.8.1和Django+1.5.1上，使用来自上述@Potr的原始响应不适用于我。我在下面发布了对我有用的东西，希望能对其他人有所帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1481425|from+south.db+import+db
from+south.v2+import+SchemaMigration
from+django.db+import+models

class+Migration(SchemaMigration):

++++def+forwards(self,+orm):
++++++++db.rename_table('common_cat',+'specific_cat')+

++++++++if+not+db.dry_run:
+++++++++++++db.execute(
++++++++++++++++"update+django_content_type+set+app_label+=+'specific'+where+"
++++++++++++++++"+app_label+=+'common'+and+model+=+'cat';")

++++def+backwards(self,+orm):
++++++++db.rename_table('specific_cat',+'common_cat')
++++++++++++db.execute(
++++++++++++++++"update+django_content_type+set+app_label+=+'common'+where+"
++++++++++++++++"+app_label+=+'specific'+and+model+=+'cat';")|code-block|syntax|javascript|1481426|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

<p>So using the the original response from @Potr above did not work
for me on South 0.8.1 and Django 1.5.1. I am posting what did 
work for me below in the hope that it is helpful to others.</p>

<pre><code>from south.db import db
from south.v2 import SchemaMigration
from django.db import models

class Migration(SchemaMigration):

    def forwards(self, orm):
        db.rename_table('common_cat', 'specific_cat') 

        if not db.dry_run:
             db.execute(
                "update django_content_type set app_label = 'specific' where "
                " app_label = 'common' and model = 'cat';")

    def backwards(self, orm):
        db.rename_table('specific_cat', 'common_cat')
            db.execute(
                "update django_content_type set app_label = 'common' where "
                " app_label = 'specific' and model = 'cat';")
</code></pre>


blocks|key|1481480|text|我将对Daniel+Roseman在他的回答中提出的一件事给出一个更明确的版本……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1481481|如果只更改模型的Django属性，使其指向现有的表名称(而不是db_table在删除并执行syncdb时会给出的新名称)，那么就可以避免复杂的南向迁移。例如：|offset|length|style|CODE|1481482|原件：|1481483|#+app1/models.py
class+MyModel(models.Model):
++++...|code-block|syntax|javascript|1481484|移动后：|1481485|#+app2/models.py
class+MyModel(models.Model):
++++class+Meta:
++++++++db_table+=+"app1_mymodel"|1481486|现在，您只需要执行数据迁移来更新django_content_type表中MyModel的app_label，您就应该可以开始了……|1481487|运行./manage.py+datamigration+django+update_content_type，然后编辑South为您创建的文件：|1481488|def+forwards(self,+orm):
++++moved+=+orm.ContentType.objects.get(app_label='app1',+model='mymodel')
++++moved.app_label+=+'app2'
++++moved.save()

def+backwards(self,+orm):
++++moved+=+orm.ContentType.objects.get(app_label='app2',+model='mymodel')
++++moved.app_label+=+'app1'
++++moved.save()|1481489|entityMap^0|0|V|8|19|6|0|0|0|0|0|G|J|11|7|19|9|0|2|1G|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@$D|12|E|13|F|G]|$D|14|E|15|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|17|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|19|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|1A|8|@$D|1B|E|1C|F|G]|$D|1D|E|1E|F|G]|$D|1F|E|1G|F|G]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1H|8|@$D|1I|E|1J|F|G]]|9|@]|A|$]]|$1|W|3|X|5|L|7|1K|8|@]|9|@]|A|$M|N]]|$1|Y|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|Z|$]]

<p>I'm going to give a more explicit version of one of the things Daniel Roseman suggested in his answer...</p>

<p>If you just change the <code>db_table</code> Meta attribute of the model you have moved to point to the existing table name (instead of the new name Django would give it if you dropped and did a <code>syncdb</code>) then you can avoid complicated South migrations. eg:</p>

<p>Original:</p>

<pre><code># app1/models.py
class MyModel(models.Model):
    ...
</code></pre>

<p>After moving:</p>

<pre><code># app2/models.py
class MyModel(models.Model):
    class Meta:
        db_table = "app1_mymodel"
</code></pre>

<p>Now you just need to do a data migration to update the <code>app_label</code> for <code>MyModel</code> in the  <code>django_content_type</code> table and you should be good to go...</p>

<p>Run <code>./manage.py datamigration django update_content_type</code> then edit the file that South creates for you:</p>

<pre><code>def forwards(self, orm):
    moved = orm.ContentType.objects.get(app_label='app1', model='mymodel')
    moved.app_label = 'app2'
    moved.save()

def backwards(self, orm):
    moved = orm.ContentType.objects.get(app_label='app2', model='mymodel')
    moved.app_label = 'app1'
    moved.save()
</code></pre>


blocks|key|1481532|text|这个过程我现在已经决定了，因为我已经回到这里几次了，并决定将其正式化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1481533|这最初是在Potr+Czachur's+answer和Matt+Briançon's+answer上构建的，使用South+0.8.4|offset|length|1481534|步骤1.发现子外键关系|1481535|#+Caution:+This+finds+OneToOneField+and+ForeignKey.
#+I+don't+know+if+this+finds+all+the+ways+of+specifying+ManyToManyField.
#+Hopefully+Django+or+South+throw+errors+if+you+have+a+situation+like+that.
>>>+Cat._meta.get_all_related_objects()
[<RelatedObject:+common:toy+related+to+cat>,
+<RelatedObject:+identity:microchip+related+to+cat>]|code-block|syntax|javascript|1481536|所以在这个扩展的例子中，我们发现了另一个相关的模型，比如：|1481537|#+Inside+the+"identity"+app...
class+Microchip(models.Model):

++++#+In+reality+we'd+probably+want+a+ForeignKey,+but+to+show+the+OneToOneField
++++identifies+=+models.OneToOneField(Cat)

++++...|1481538|步骤2.创建迁移|1481539|#+Create+the+"new"-ly+renamed+model
#+Yes+I'm+changing+the+model+name+in+my+refactoring+too.
python+manage.py+schemamigration+specific+create_kittycat+--auto

#+Drop+the+old+model
python+manage.py+schemamigration+common+drop_cat+--auto

#+Update+downstream+apps,+so+South+thinks+their+ForeignKey(s)+are+correct.
#+Can+skip+models+like+Toy+if+the+app+is+already+covered
python+manage.py+schemamigration+identity+update_microchip_fk+--auto|1481540|步骤3.源代码控制:到目前为止提交更改。|1481541|如果你遇到合并冲突，比如团队成员在更新的应用程序上编写迁移，这将使其更具可重复性。|1481542|步骤4.在迁移之间添加依赖关系。|1481543|基本上，create_kittycat依赖于所有内容的当前状态，然后所有内容都依赖于create_kittycat。|style|CODE|1481544|#+create_kittycat
class+Migration(SchemaMigration):

++++depends_on+=+(
++++++++#+Original+model+location
++++++++('common',+'the_one_before_drop_cat'),

++++++++#+Foreign+keys+to+models+not+in+original+location
++++++++('identity',+'the_one_before_update_microchip_fk'),
++++)
++++...


#+drop_cat
class+Migration(SchemaMigration):

++++depends_on+=+(
++++++++('specific',+'create_kittycat'),
++++)
++++...


#+update_microchip_fk
class+Migration(SchemaMigration):

++++depends_on+=+(
++++++++('specific',+'create_kittycat'),
++++)
++++...|1481545|步骤5.我们想要进行的表重命名更改。|1481546|#+create_kittycat
class+Migration(SchemaMigration):

++++...

++++#+Hopefully+for+create_kittycat+you+only+need+to+change+the+following
++++#+4+strings+to+go+forward+cleanly...+backwards+will+need+a+bit+more+work.
++++old_app+=+'common'
++++old_model+=+'cat'
++++new_app+=+'specific'
++++new_model+=+'kittycat'

++++#+You+may+also+wish+to+update+the+ContentType.name,
++++#+personally,+I+don't+know+what+its+for+and
++++#+haven't+seen+any+side+effects+from+skipping+it.

++++def+forwards(self,+orm):

++++++++db.rename_table(
++++++++++++'%25s_%25s'+%25+(self.old_app,+self.old_model),
++++++++++++'%25s_%25s'+%25+(self.new_app,+self.new_model),
++++++++)

++++++++if+not+db.dry_run:
++++++++++++#+For+permissions,+GenericForeignKeys,+etc+to+work+properly+after+migrating.
++++++++++++orm['contenttypes.contenttype'].objects.filter(
++++++++++++++++app_label=self.old_app,
++++++++++++++++model=self.old_model,
++++++++++++).update(
++++++++++++++++app_label=self.new_app,
++++++++++++++++model=self.new_model,
++++++++++++)

++++++++#+Going+forwards,+should+be+no+problem+just+updating+child+foreign+keys
++++++++#+with+the+--auto+in+the+other+new+South+migrations

++++def+backwards(self,+orm):

++++++++db.rename_table(
++++++++++++'%25s_%25s'+%25+(self.new_app,+self.new_model),
++++++++++++'%25s_%25s'+%25+(self.old_app,+self.old_model),
++++++++)

++++++++if+not+db.dry_run:
++++++++++++#+For+permissions,+GenericForeignKeys,+etc+to+work+properly+after+migrating.
++++++++++++orm['contenttypes.contenttype'].objects.filter(
++++++++++++++++app_label=self.new_app,
++++++++++++++++model=self.new_model,
++++++++++++).update(
++++++++++++++++app_label=self.old_app,
++++++++++++++++model=self.old_model,
++++++++++++)

++++++++#+Going+backwards,+you+probably+should+copy+the+ForeignKey
++++++++#+db.alter_column()+changes+from+the+other+new+migrations+in+here
++++++++#+so+they+run+in+the+correct+order.
++++++++#
++++++++#+Test+it!+See+Step+6+for+more+details+if+you+need+to+go+backwards.
++++++++db.alter_column('common_toy',+'belongs_to_id',+self.gf('django.db.models.fields.related.ForeignKey')(to=orm['common.Cat']))
++++++++db.alter_column('identity_microchip',+'identifies_id',+self.gf('django.db.models.fields.related.OneToOneField')(to=orm['common.Cat']))


#+drop_cat
class+Migration(SchemaMigration):

++++...

++++def+forwards(self,+orm):
++++++++#+Remove+the+db.delete_table(),+if+you+don't+at+Step+7+you'll+likely+get
++++++++#+"django.db.utils.ProgrammingError:+table+"common_cat"+does+not+exist"

++++++++#+Leave+existing+db.alter_column()+statements+here
++++++++db.alter_column('common_toy',+'belongs_to_id',+self.gf('django.db.models.fields.related.ForeignKey')(to=orm['specific.KittyCat']))

++++def+backwards(self,+orm):
++++++++#+Copy/paste+the+auto-generated+db.alter_column()
++++++++#+into+the+create_kittycat+migration+if+you+need+backwards+to+work.
++++++++pass


#+update_microchip_fk
class+Migration(SchemaMigration):

++++...

++++def+forwards(self,+orm):
++++++++#+Leave+existing+db.alter_column()+statements+here
++++++++db.alter_column('identity_microchip',+'identifies_id',+self.gf('django.db.models.fields.related.OneToOneField')(to=orm['specific.KittyCat']))

++++def+backwards(self,+orm):
++++++++#+Copy/paste+the+auto-generated+db.alter_column()
++++++++#+into+the+create_kittycat+migration+if+you+need+backwards+to+work.
++++++++pass|1481547|第6步。仅当您需要使用backwards()来工作并让KeyError向后运行时。|1481548|#+the_one_before_create_kittycat
class+Migration(SchemaMigration):

++++#+You+many+also+need+to+add+more+models+to+South's+FakeORM+if+you+run+into
++++#+more+KeyErrors,+the+trade-off+chosen+was+to+make+going+forward+as+easy+as
++++#+possible,+as+that's+what+you'll+probably+want+to+do+once+in+QA+and+once+in
++++#+production,+rather+than+running+the+following+many+times:
++++#
++++#+python+manage.py+migrate+specific+<the_one_before_create_kittycat>

++++models+=+{
++++++++...
++++++++#+Copied+from+'identity'+app,+'update_microchip_fk'+migration
++++++++u'identity.microchip':+{
++++++++++++'Meta':+{'object_name':+'Microchip'},
++++++++++++u'id':+('django.db.models.fields.AutoField',+[],+{'primary_key':+'True'}),
++++++++++++'name':+('django.db.models.fields.CharField',+[],+{'unique':+'True',+'max_length':+'80'}),
++++++++++++'identifies':+('django.db.models.fields.related.OneToOneField',+[],+{to=orm['specific.KittyCat']})
++++++++},
++++++++...
++++}|1481549|第7步.测试它-对我有效的可能不足以满足您的实际情况:)|1481550|python+manage.py+migrate

#+If+you+need+backwards+to+work
python+manage.py+migrate+specific+<the_one_before_create_kittycat>|1481551|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/1770138/305736|1|https://stackoverflow.com/a/12080790^0|0|5|L|0|R|M|1|0|0|0|0|0|0|0|0|0|0|4|F|16|F|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1T|8|@]|9|@$D|1U|E|1V|1|1W]|$D|1X|E|1Y|1|1Z]]|A|$]]|$1|F|3|G|5|6|7|20|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|21|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|22|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|23|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|24|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|25|8|@]|9|@]|A|$K|L]]|$1|U|3|V|5|6|7|26|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|27|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|28|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|29|8|@$D|2A|E|2B|12|13]|$D|2C|E|2D|12|13]]|9|@]|A|$]]|$1|14|3|15|5|J|7|2E|8|@]|9|@]|A|$K|L]]|$1|16|3|17|5|6|7|2F|8|@]|9|@]|A|$]]|$1|18|3|19|5|J|7|2G|8|@]|9|@]|A|$K|L]]|$1|1A|3|1B|5|6|7|2H|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|J|7|2I|8|@]|9|@]|A|$K|L]]|$1|1E|3|1F|5|6|7|2J|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|J|7|2K|8|@]|9|@]|A|$K|L]]|$1|1I|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]]|1J|$1K|$5|1L|1M|1N|A|$1O|1P]]|1Q|$5|1L|1M|1N|A|$1O|1R]]]]

<p>The process I've currently settled on since I've been back here a few times and decided to formalise it.</p>

<p>This was originally built on 
<a href="https://stackoverflow.com/a/1770138/305736">Potr Czachur's answer</a>
and <a href="https://stackoverflow.com/a/12080790">Matt Briançon's answer</a>,
using South 0.8.4</p>

<h2>Step 1. Discover child foreign key relationships</h2>

<pre><code># Caution: This finds OneToOneField and ForeignKey.
# I don't know if this finds all the ways of specifying ManyToManyField.
# Hopefully Django or South throw errors if you have a situation like that.
&gt;&gt;&gt; Cat._meta.get_all_related_objects()
[&lt;RelatedObject: common:toy related to cat&gt;,
 &lt;RelatedObject: identity:microchip related to cat&gt;]
</code></pre>

<p>So in this extended case, we have discovered another related model like:</p>

<pre><code># Inside the "identity" app...
class Microchip(models.Model):

    # In reality we'd probably want a ForeignKey, but to show the OneToOneField
    identifies = models.OneToOneField(Cat)

    ...
</code></pre>

<h2>Step 2. Create migrations</h2>

<pre><code># Create the "new"-ly renamed model
# Yes I'm changing the model name in my refactoring too.
python manage.py schemamigration specific create_kittycat --auto

# Drop the old model
python manage.py schemamigration common drop_cat --auto

# Update downstream apps, so South thinks their ForeignKey(s) are correct.
# Can skip models like Toy if the app is already covered
python manage.py schemamigration identity update_microchip_fk --auto
</code></pre>

<h2>Step 3. Source control: Commit changes so far.</h2>

<p>Makes it a more repeatable process if you run into merge conflicts like team mates writing migrations on the updated apps.</p>

<h2>Step 4. Add dependencies between the migrations.</h2>

<p>Basically <code>create_kittycat</code> depends on the current state of everything, and everything then depends on <code>create_kittycat</code>.</p>

<pre><code># create_kittycat
class Migration(SchemaMigration):

    depends_on = (
        # Original model location
        ('common', 'the_one_before_drop_cat'),

        # Foreign keys to models not in original location
        ('identity', 'the_one_before_update_microchip_fk'),
    )
    ...


# drop_cat
class Migration(SchemaMigration):

    depends_on = (
        ('specific', 'create_kittycat'),
    )
    ...


# update_microchip_fk
class Migration(SchemaMigration):

    depends_on = (
        ('specific', 'create_kittycat'),
    )
    ...
</code></pre>

<h2>Step 5. The table rename change we want to make.</h2>

<pre><code># create_kittycat
class Migration(SchemaMigration):

    ...

    # Hopefully for create_kittycat you only need to change the following
    # 4 strings to go forward cleanly... backwards will need a bit more work.
    old_app = 'common'
    old_model = 'cat'
    new_app = 'specific'
    new_model = 'kittycat'

    # You may also wish to update the ContentType.name,
    # personally, I don't know what its for and
    # haven't seen any side effects from skipping it.

    def forwards(self, orm):

        db.rename_table(
            '%s_%s' % (self.old_app, self.old_model),
            '%s_%s' % (self.new_app, self.new_model),
        )

        if not db.dry_run:
            # For permissions, GenericForeignKeys, etc to work properly after migrating.
            orm['contenttypes.contenttype'].objects.filter(
                app_label=self.old_app,
                model=self.old_model,
            ).update(
                app_label=self.new_app,
                model=self.new_model,
            )

        # Going forwards, should be no problem just updating child foreign keys
        # with the --auto in the other new South migrations

    def backwards(self, orm):

        db.rename_table(
            '%s_%s' % (self.new_app, self.new_model),
            '%s_%s' % (self.old_app, self.old_model),
        )

        if not db.dry_run:
            # For permissions, GenericForeignKeys, etc to work properly after migrating.
            orm['contenttypes.contenttype'].objects.filter(
                app_label=self.new_app,
                model=self.new_model,
            ).update(
                app_label=self.old_app,
                model=self.old_model,
            )

        # Going backwards, you probably should copy the ForeignKey
        # db.alter_column() changes from the other new migrations in here
        # so they run in the correct order.
        #
        # Test it! See Step 6 for more details if you need to go backwards.
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['common.Cat']))
        db.alter_column('identity_microchip', 'identifies_id', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['common.Cat']))


# drop_cat
class Migration(SchemaMigration):

    ...

    def forwards(self, orm):
        # Remove the db.delete_table(), if you don't at Step 7 you'll likely get
        # "django.db.utils.ProgrammingError: table "common_cat" does not exist"

        # Leave existing db.alter_column() statements here
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['specific.KittyCat']))

    def backwards(self, orm):
        # Copy/paste the auto-generated db.alter_column()
        # into the create_kittycat migration if you need backwards to work.
        pass


# update_microchip_fk
class Migration(SchemaMigration):

    ...

    def forwards(self, orm):
        # Leave existing db.alter_column() statements here
        db.alter_column('identity_microchip', 'identifies_id', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['specific.KittyCat']))

    def backwards(self, orm):
        # Copy/paste the auto-generated db.alter_column()
        # into the create_kittycat migration if you need backwards to work.
        pass
</code></pre>

<h2>Step 6. Only if you need backwards() to work AND get a KeyError running backwards.</h2>

<pre><code># the_one_before_create_kittycat
class Migration(SchemaMigration):

    # You many also need to add more models to South's FakeORM if you run into
    # more KeyErrors, the trade-off chosen was to make going forward as easy as
    # possible, as that's what you'll probably want to do once in QA and once in
    # production, rather than running the following many times:
    #
    # python manage.py migrate specific &lt;the_one_before_create_kittycat&gt;

    models = {
        ...
        # Copied from 'identity' app, 'update_microchip_fk' migration
        u'identity.microchip': {
            'Meta': {'object_name': 'Microchip'},
            u'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}),
            'name': ('django.db.models.fields.CharField', [], {'unique': 'True', 'max_length': '80'}),
            'identifies': ('django.db.models.fields.related.OneToOneField', [], {to=orm['specific.KittyCat']})
        },
        ...
    }
</code></pre>

<h2>Step 7. Test it - what works for me may not be enough for your real life situation :)</h2>

<pre><code>python manage.py migrate

# If you need backwards to work
python manage.py migrate specific &lt;the_one_before_create_kittycat&gt;
</code></pre>


<p>I have a django app with four models in it. I realize now that one of these models should be in a separate app. I do have south installed for migrations, but I don't think this is something it can handle automatically. How can I migrate one of the models out of the old app into a new one?</p>

<p>Also, keep in mind that I'm going to need this to be a repeatable process, so that I can migrate the production system and such. </p>


How do I migrate a model out of one django app and into a new one?

数据迁移

数据库

Django

我有一个django应用程序，里面有四个模型。我现在意识到，这些模型中的一个应该放在单独的应用程序中。我确实为迁移安装了south，但我不认为这是它可以自动处理的事情。如何将旧应用程序中的一个模型迁移到新应用程序中？此外，请记住，我需要这是一个可重复的过程，以便我可以迁移生产系统等。

问如何将模型从django应用程序迁移到新的应用程序？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何将模型从django应用程序迁移到新的应用程序？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何将模型从django应用程序迁移到新的应用程序？
EN