Ошибка миграции Django на юг с уникальным полем в базе данных postgresql - PullRequest
Новая
       5

Ошибка миграции Django на юг с уникальным полем в базе данных postgresql

2 голосов
/ 13 августа 2011

Редактировать: Я понимаю причину, почему это произошло. Это было из-за существования файла 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) уже существует.

Я хочу сохранить это поле уникальным, но все же перенести поле. Между прочим, потеря данных в этой таблице является приемлемой, если другие таблицы в БД остаются неизменными.

1 Ответ

1 голос
/ 14 августа 2011

Это стандартное поведение 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', в противном случае поведение по умолчанию вступит во владение.

...