标签: django-migrations

我正在使用Django 1.7.1.我的模型看起来像这样:

from datetime import datetime
from django.db import models

class myModel(models.Model):
    x = models.CharField(max_length=254,null=True, blank=True,)

一切都很好.

但是,当我将以下属性添加到myModel时,它会中断:

    y = models.DateTimeField(default=lambda: datetime.utcnow() + timedelta(days=1), editable=False)

manage.py makemigrations 给我以下错误:

ValueError: Cannot serialize function: lambda

这似乎是一个已知的错误:http://comments.gmane.org/gmane.comp.python.django.scm/125724

那么我该如何解决呢？y从创建模型的那一刻起,我需要将默认值自动设置为24小时.

当我运行测试时,我在数据库初始化期间遇到此错误:

django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'users.GroupProxy'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth)

我为contrib.auth Group模型创建了这个代理,将它放在django admin的应用程序中:

class GroupProxy(Group):
    class Meta:
        proxy = True
        verbose_name = Group._meta.verbose_name
        verbose_name_plural = Group._meta.verbose_name_plural

那么我该怎么做才能解决这个问题呢？

从Django 1.8开始,该makemigrations命令可以--name, -n 选择为创建的迁移文件指定自定义名称.

我想知道在旧版本的Django中使用自动生成的名称创建迁移文件是否安全,然后手动重命名该文件.它似乎按预期工作.有潜在的风险吗？

--fake-initial和--fakeDjango迁移有什么区别？使用虚假迁移有哪些危险？有人知道吗？非常感谢大家.

我正在使用django 1.10

我正在使用django 1.7,我刚刚添加了一个自定义用户模型.当我运行任何一个python3 manage.py makemigrations或python3 manage.py migrate我得到错误:TypeError: __init__() got an unexpected keyword argument 'preserve_default'.添加新的自定义用户模型后出现此问题.完整的追溯是:

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 338, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.4/dist-packages/django/core/management/commands/migrate.py", line 63, in handle
    executor = MigrationExecutor(connection, self.migration_progress_callback)
  File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 17, in __init__
    self.loader …

如果我有一个不可为空的模型字段,删除它,并创建一个迁移,那么迁移将变为不可逆:

考虑以下模型:

class Foo(models.Model):
    bar = models.TextField()
    test = models.TextField()  # This field is to go away, bye-bye!

和迁移:

# app/migrations/003_remove_foo_test.py

class Migration(migrations.Migration):

    dependencies = [
        ('app', '0002_foo_test'),
    ]

    operations = [
        migrations.RemoveField(
            model_name='foo',
            name='test',
        ),
    ]

取消应用此迁移会引发异常:

$ src/manage.py migrate app 0002
Operations to perform:
  Target specific migration: 0002_foo_test, from app
Running migrations:
  Unapplying app.0003_remove_foo_test...Traceback (most recent call last):
...
django.db.utils.IntegrityError: column "test" contains null values

当然,这是预期的行为,它是清楚记录的,我不是在问为什么会发生这种情况:

请记住,当反转时,这实际上是在模型中添加一个字段; 如果该字段不可为空,则可能使该操作不可逆转(除了任何数据丢失,这当然是不可逆转的).

但是,我们都会犯错误,有时我们只需要以某种方式反转字段删除,即使这意味着手动为所有反转的非空字段提供临时存根值.例如,南迁移可选择允许逆转此类操作(通过询问开发人员是否为恢复的字段提供默认值,或禁止反向迁移),这似乎不是所有新奇特的Django 1.7迁移的情况. .

问题:使用Django …

我知道Django中的游标对象.在迁移中是否还有其他首选方法可以执行原始SQL？我想为我的一个模型表引入postgresql分区.分区逻辑是一系列功能和触发器,必须在我想要自动化的设置中添加到数据库中.

我已经成为Django的用户大约2年了,并且有一个我一直害怕使用的功能:伪造迁移.

我几乎到处都看了,我能得到的最多信息来自文档,其中说明:

- 假

告诉Django将迁移标记为已应用或未应用,但没有实际运行SQL来更改数据库架构.

这适用于高级用户在手动应用更改时直接操作当前迁移状态; 请注意,使用--fake会冒着将迁移状态表置于需要手动恢复以使迁移正确运行的状态的风险.

--fake-初始

如果所有具有该迁移中所有CreateModel操作创建的模型名称的数据库表已存在,则允许Django跳过应用程序的初始迁移.此选项适用于首次针对预先存在使用迁移的数据库运行迁移时使用.但是,此选项不会检查匹配的表名称之外的匹配数据库模式,因此只有在您确信现有模式与初始迁移中记录的模式匹配时才可以安全使用.

我得到了一般的想法以及为什么人们想要使用这个功能.但是,我不明白它所说的部分仅适用于高级用户.

有人可以解释幕后发生的事情以及为什么需要手动恢复.

注意

我不是在寻找伪造迁移时运行的确切原始SQL查询.我只是在寻找关于场景背后发生的事情的一般概念,也许是为什么伪造迁移会导致状态makemigrations无法正常工作的一个例子.

我在我的应用程序中创建了一些动态Django模型,除了迁移系统外,一切似乎都按预期工作.

如果我创建一个动态Django模型并设置managed = False,Django的makemigrations命令仍会为该新模型生成一个迁移.迁移看起来像这样:

class Migration(migrations.Migration):

    dependencies = [
        ('atom', '0001_initial'),
    ]

    operations = [
        migrations.CreateModel(
            name='books',
            fields=[
            ],
            options={
                'db_table': 'books',
                'managed': False,
            },
            bases=(models.Model,),
        ),
    ]

如果我不创建迁移,当我运行时python manage.py migrate,我会看到以下消息(用可怕的红色字母表示):

Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

有没有办法告诉Django 1.7中的迁移系统一起忽略非托管模型？或者migrations = False模型的Meta类中的设置？

更新:为了澄清,我使用一种方法来创建我的动态模型,类似于以下地方描述的模型:

• http://dynamic-models.readthedocs.org/en/latest/topics/model.html#topics-model
• https://code.djangoproject.com/wiki/DynamicModels

此方法非常适合根据存储在配置模型中的信息生成动态模型(https://code.djangoproject.com/wiki/DynamicModels#Adatabase-drivenapproach).我确实需要注册一个信号来清除django模型缓存,以便在更改Configuration实例时捕获对模型的更改,但除了为这些模型生成迁移之外,一切似乎都很好.如果我删除其中一个配置并从Django的缓存中删除模型,则需要再次更新迁移,删除它不应该关心的模型. …

运行时python manage.py migrate遇到此错误:

django.db.migrations.exceptions.InconsistentMigrationHistory: Migration
<appname>.0016_auto_<date2>_<time2> is applied before its dependency
<appname>.0001_squashed_0015_auto_<date1>_<time1>

运行showmigrations返回:

<appname>
 [X] 0001_squashed_0015_auto_<date1>_<time1> (15 squashed migrations)
 [X] 0016_auto_<date2>_<time2>
 [ ] 0017_<modelname>_squashed_0019_auto_<date3>_<time3> (3 squashed migrations)

我昨天尝试了django-extensions,当我运行一些直接的SQL查询并且使用git重置后,它都搞砸了.我还在学习迁移,所以我不明白什么是错的,因为在我看来这两个迁移都已经应用了.

谢谢您的帮助!