使用south重构带有inheritan的Django模型

Question

我想知道Django south是否可以进行以下迁移，并且仍然保留数据。

之前：

我现在有两个应用程序，一个叫电视，一个叫电影，每个都有一个视频文件模型（这里简化了）：

电视/型号.py:

class VideoFile(models.Model):
    show = models.ForeignKey(Show, blank=True, null=True)
    name = models.CharField(max_length=1024, blank=True)
    size = models.IntegerField(blank=True, null=True)
    ctime = models.DateTimeField(blank=True, null=True)

电影/模型.py:

class VideoFile(models.Model):
    movie = models.ForeignKey(Movie, blank=True, null=True)
    name = models.CharField(max_length=1024, blank=True)
    size = models.IntegerField(blank=True, null=True)
    ctime = models.DateTimeField(blank=True, null=True)

之后：

因为这两个videofile对象非常相似，所以我希望消除重复，并在一个名为media的单独应用程序中创建一个新模型，该应用程序包含一个通用的videofile类，并使用继承来扩展它：

媒体/模型.py:

class VideoFile(models.Model):
    name = models.CharField(max_length=1024, blank=True)
    size = models.IntegerField(blank=True, null=True)
    ctime = models.DateTimeField(blank=True, null=True)

电视/型号.py:

class VideoFile(media.models.VideoFile):
    show = models.ForeignKey(Show, blank=True, null=True)

电影/模型.py:

class VideoFile(media.models.VideoFile):
    movie = models.ForeignKey(Movie, blank=True, null=True)

所以我的问题是，我怎样才能在django south上完成这项工作，并且仍然保持现有的数据？

所有这三个应用程序都已经由south migrations管理，根据south文档，将模式和数据迁移结合起来是不好的做法，他们建议应该在几个步骤中完成。

我认为可以使用这样的单独迁移来完成（假设已经创建了media.VideoFile）

1. 架构迁移以重命名tv.VideoFile和movies.VideoFile中的所有字段，这些字段将移动到新的media.VideoFile模型，可能是旧名称、旧大小等
2. 架构迁移到tv.VideoFile和movies.VideoFile以从media.VideoFile继承
3. 数据迁移以将旧名称复制到名称、旧大小复制到大小等
4. 方案迁移以删除旧字段

在我完成所有的工作之前，你认为那会成功吗？有更好的办法吗？

如果您感兴趣，该项目将托管在这里：http://code.google.com/p/medianav/

Answer 1

查看以下Paul的回复，了解有关与Django/South新版本兼容的一些注意事项。

---

这似乎是一个有趣的问题，我正在成为一个南方的大粉丝，所以我决定调查一下。我在上面描述的抽象基础上构建了一个测试项目，并成功地使用South执行了您所要求的迁移。在我们开始代码之前，这里有几个注意事项：

• South文档建议分别执行模式迁移和数据迁移。我也跟着做了。

• 在后端，Django通过在继承模型上自动创建OneToOne字段来表示继承的表

• 了解到这一点，我们的South迁移需要手动正确处理OneToOne字段，然而，在实验中，South（或者Django本身）似乎无法在多个同名继承表上创建OneToOne字段。因此，我将movies/tv应用程序中的每个子表重命名为各自的应用程序（即MovieVideoFile/ShowVideoFile）。

• 在处理实际的数据迁移代码时，South似乎更喜欢先创建OneToOne字段，然后将数据分配给它。在创建期间将数据分配给OneToOne字段会导致South阻塞。（一个公平的妥协，所有的凉爽是南方）。

所以说了这么多，我试着记录下正在发出的控制台命令。必要时我会插一句评论。最后的代码在底部。

命令历史记录

django-admin.py startproject southtest
manage.py startapp movies
manage.py startapp tv
manage.py syncdb
manage.py startmigration movies --initial
manage.py startmigration tv --initial
manage.py migrate
manage.py shell          # added some fake data...
manage.py startapp media
manage.py startmigration media --initial
manage.py migrate
# edited code, wrote new models, but left old ones intact
manage.py startmigration movies unified-videofile --auto
# create a new (blank) migration to hand-write data migration
manage.py startmigration movies videofile-to-movievideofile-data 
manage.py migrate
# edited code, wrote new models, but left old ones intact
manage.py startmigration tv unified-videofile --auto
# create a new (blank) migration to hand-write data migration
manage.py startmigration tv videofile-to-movievideofile-data
manage.py migrate
# removed old VideoFile model from apps
manage.py startmigration movies removed-videofile --auto
manage.py startmigration tv removed-videofile --auto
manage.py migrate

为了节省空间，而且由于模型最终看起来总是一样的，我只想用“电影”应用程序演示一下。

电影/模型.py

from django.db import models
from media.models import VideoFile as BaseVideoFile

# This model remains until the last migration, which deletes 
# it from the schema.  Note the name conflict with media.models
class VideoFile(models.Model):
    movie = models.ForeignKey(Movie, blank=True, null=True)
    name = models.CharField(max_length=1024, blank=True)
    size = models.IntegerField(blank=True, null=True)
    ctime = models.DateTimeField(blank=True, null=True)

class MovieVideoFile(BaseVideoFile):
    movie = models.ForeignKey(Movie, blank=True, null=True, related_name='shows')

movies/migrations/0002_unified-videofile.py（架构迁移）

from south.db import db
from django.db import models
from movies.models import *

class Migration:

    def forwards(self, orm):

        # Adding model 'MovieVideoFile'
        db.create_table('movies_movievideofile', (
            ('videofile_ptr', orm['movies.movievideofile:videofile_ptr']),
            ('movie', orm['movies.movievideofile:movie']),
        ))
        db.send_create_signal('movies', ['MovieVideoFile'])

    def backwards(self, orm):

        # Deleting model 'MovieVideoFile'
        db.delete_table('movies_movievideofile')

movies/migration/0003_videofile-to-movievideofile-data.py（数据迁移）

from south.db import db
from django.db import models
from movies.models import *

class Migration:

    def forwards(self, orm):
        for movie in orm['movies.videofile'].objects.all():
            new_movie = orm.MovieVideoFile.objects.create(movie = movie.movie,)
            new_movie.videofile_ptr = orm['media.VideoFile'].objects.create()

            # videofile_ptr must be created first before values can be assigned
            new_movie.videofile_ptr.name = movie.name
            new_movie.videofile_ptr.size = movie.size
            new_movie.videofile_ptr.ctime = movie.ctime
            new_movie.videofile_ptr.save()

    def backwards(self, orm):
        print 'No Backwards'

南方太棒了！

好的，标准免责声明：你在处理实时数据。我已经给了您工作代码，但是请使用--db-dry-run来测试您的模式。在尝试任何事情之前都要做备份，通常要小心。

兼容性注意事项

我将保持原始消息的完整性，但是South已经将命令manage.py startmigration更改为manage.py schemamigration。