Django南迁移错误与postgresql数据库中的唯一字段

发布于 2024-11-29 05:11:28 字数 774 浏览 1 评论 0原文

编辑:我明白发生这种情况的原因。这是因为“initial_data.json”文件的存在。显然,南想要在迁移后添加这些固定装置,但由于场地的独特属性而失败。

我从此更改了模型:

class Setting(models.Model):
    anahtar = models.CharField(max_length=20,unique=True)
    deger = models.CharField(max_length=40)

    def __unicode__(self):
        return self.anahtar

对此,

class Setting(models.Model):
    anahtar = models.CharField(max_length=20,unique=True)
    deger = models.CharField(max_length=100)

    def __unicode__(self):
        return self.anahtar

架构迁移命令已成功完成,但是尝试迁移会出现此错误:

IntegrityError:重复的键值违反了唯一约束 “blog_setting_anahtar_key”详细信息:密钥(anahtar)=(blog_baslik)已经 存在。

我想保持该字段的唯一性,但仍会迁移该字段。顺便说一句,只要数据库中的其他表保持不变,该表上的数据丢失是可以接受的。

Edit: I understand the reason why this happened. It was because of the existence of `initial_data.json` file. Apparently, south wants to add those fixtures after migration but failing because of the unique property of a field.

I changed my model from this:

class Setting(models.Model):
    anahtar = models.CharField(max_length=20,unique=True)
    deger = models.CharField(max_length=40)

    def __unicode__(self):
        return self.anahtar

To this,

class Setting(models.Model):
    anahtar = models.CharField(max_length=20,unique=True)
    deger = models.CharField(max_length=100)

    def __unicode__(self):
        return self.anahtar

Schema migration command completed successfully, but, trying to migrate gives me this error:

IntegrityError: duplicate key value violates unique constraint
"blog_setting_anahtar_key" DETAIL: Key (anahtar)=(blog_baslik) already
exists.

I want to keep that field unique, but still migrate the field. By the way, data loss on that table is acceptable, so long as other tables in DB stay intact.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

空城之時有危險 2024-12-06 05:11:28

这实际上是syncdb每次运行initial_data.json的默认行为。来自 Django 文档:

如果您创建一个名为initial_data.[xml/yaml/json]的固定装置,则每次运行syncdb时都会加载该固定装置。这非常方便,但要小心:记住每次运行syncdb 时数据都会刷新。因此,请勿将initial_data 用于您要编辑的数据。

请参阅:文档

就我个人而言,我认为每次发生更改时都需要重新加载初始数据的用例是延迟的,所以我从不使用initial_data.json。

由于您使用的是 South,更好的方法是在迁移所需的特定设备上手动调用 loaddata。对于初始数据,它将进入您的 0001_initial.py 迁移。

def forwards(self, orm):
    from django.core.management import call_command
    call_command("loaddata", "my_fixture.json")

请参阅:http://south.aeracode.org/docs/fixtures.html

另外,请记住您的装置的路径是相对于项目根目录的。因此,如果您的装置位于“myproject/myapp/fixtures/my_fixture.json”call_command 实际上看起来像:

call_command('loaddata', 'myapp/fixtures/my_fixture.json')

而且,当然,您的装置不能命名为“initial_data.json”,否则,默认行为将接管。

It's actually the default behavior of syncdb to run initial_data.json each time. From the Django docs:

If you create a fixture named initial_data.[xml/yaml/json], that fixture will be loaded every time you run syncdb. This is extremely convenient, but be careful: remember that the data will be refreshed every time you run syncdb. So don't use initial_data for data you'll want to edit.

See: docs

Personally, I think the use-case for initial data that needs to be reloaded each and every time a change occurs is retarded, so I never use initial_data.json.

The better method, since you're using South, is to manually call loaddata on a specific fixture necessary for your migration. In the case of initial data, that would go in your 0001_initial.py migration.

def forwards(self, orm):
    from django.core.management import call_command
    call_command("loaddata", "my_fixture.json")

See: http://south.aeracode.org/docs/fixtures.html

Also, remember that the path to your fixture is relative to the project root. So, if your fixture is at "myproject/myapp/fixtures/my_fixture.json" call_command would actually look like:

call_command('loaddata', 'myapp/fixtures/my_fixture.json')

And, of course, your fixture can't be named 'initial_data.json', otherwise, the default behavior will take over.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文