Миграция внешнего ключа с использованием django South

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

class Activity(models.Model):
    ...
    source = models.ForeignKey(FSObject)

и стал

class Activity(models.Model):
    ...
    source = models.ForeignKey(FreezedRef)

И теперь я получаю это сообщение при запуске тестов:

IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`test_tcf_api`.`storage_activity`, CONSTRAINT `source_id_refs_id_fc96b4b044ceb88` FOREIGN KEY (`source_id`) REFERENCES `storage_fsobject` (`id`))')

Как мне удалить эту старую ссылку, видимо, Юг ее пропустил.


python mysql django django-south
person Tomás Silveira Corrêa    schedule 27.03.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Обновляли ли вы что-нибудь еще в той же миграции? Они сработали или сломались? Я спрашиваю только потому, что у меня никогда не было поломки South при выполнении миграции - обычно он вызывает исключение во время этого процесса, если что-то не так.

person Todd    schedule 27.03.2012
comment
Скорее всего, он имеет дело с идиосинкразией в mysql. Я сталкивался с этим раньше, когда одна таблица была myISAM, а другая - InnoDB. South/django создал ограничение, которое, конечно, не работает, поскольку myISAM не поддерживает внешние ключи. Не знаю точно, как оказаться на этом пути, но я уже видел точную проблему. - person John; 28.03.2012
comment
Отсюда мое первое предложение отказаться от базы данных мусора и перейти к чему-то, что не так сильно отстойно. Это лишь одна из множества проблем с использованием mysql. - person John; 29.03.2012

arrow_upward
-1
arrow_downward

  1. Прекратите использовать плохие базы данных, такие как MySQL, которые создают внутренние проблемы, подобные этой, из-за того, что это всего лишь своего рода база данных (извините, не удержался, но это правда)
  2. ALTER TABLE tbl_name DROP FOREIGN KEY fk_symbol; Прямо из документов mysql: http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html
person John    schedule 27.03.2012
comment
Почему вы считаете MySQL плохим? - person Andrew; 19.07.2012
comment
По умолчанию он не совместим удаленно с ACID, что действительно ужасно, нет ограничений по внешнему ключу, нет транзакций, невозможно индексировать поля размером более 1 КБ (вы можете возразить, что это в любом случае плохой дизайн, но все же это всего лишь 300 символов юникода), неспособность индексировать функцию результаты, отсутствие реализации EXPLAIN ANALYZE, никаких транзакций во время команд изменения схемы, запросы используют только один индекс для каждого запроса в каждой таблице (что вынуждает использовать тонны многостолбцовых индексов вместо объединения индексов на лету). Я уверен, что мог бы придумать больше, если бы потратил немного времени, в основном я нахожу что-то новое каждую неделю. - person John; 19.07.2012
comment
Очевидно, я понимаю, что пара (без fk и без транзакций) из них может помочь с innodb, большинство не может, но некоторые могут. InnoDB должен быть по умолчанию, если вы хотите играть быстро и лузово, чтобы немного повысить производительность, вы должны переключиться на MyISAM, а не наоборот. Единственное, что действительно хорошо в MySQL IMO, это то, что это была первая широко распространенная БД с открытым исходным кодом, которая открыла множество возможностей для Интернета. Что-то подобное можно сказать и о PHP, и я не думаю, что многие люди будут спорить, что PHP — потрясающий или лучший инструмент. - person John; 19.07.2012