Джанго Юг и Constraint идентификаторы

Question

При создании уникальных и ограничений внешнего ключа, как это Южная придумывают идентификатор для имени ограничения, как:

CONSTRAINT report_type_id_refs_id_435782e833badd2f FOREIGN KEY (report_type_id) 
REFERENCES reports_reporttype (id) MATCH SIMPLE 
ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED, 

Проблема, что я продолжаю ударять в том, что миграция пытается для удаления ограничения, но фактическое ограничение в базе данных отличается.

1. Этот хэш генерируется самим Югом, или он исходит из базы данных?
2. Что это за хэш на основе?

Использование PostgreSQL в качестве базы данных.

Обновление: Я заметил, что несоответствие не совсем случайное. Вот что есть база данных:

CONSTRAINT user_id_refs_id_f15cc3cd FOREIGN KEY (user_id) 
REFERENCES brandnew4.auth_user (id) MATCH SIMPLE 
ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED 

и вот contraint, что Южная пытается удалить:

django.db.utils.DatabaseError: constraint "user_id_refs_id_7e2ccc6bf15cc3cd" of relation "operatorInterface_ospreyuserprofile" does not exist 

Если посмотреть поближе на эти имена ограничений:

 user_id_refs_id_f15cc3cd 
user_id_refs_id_7e2ccc6bf15cc3cd 

8-значный hex-ключ в db совпадает с последними 8-значными цифрами 16-значный ключ, который ищет Юг.

Что происходит?

---

Update 2: Я отслеживал, где хэш получает генерируется: https://github.com/django/django/commit/e4ea53677449cfc56a0093bfbd92cb482020bb1e

Почему Юг использовать 64-разрядную версию хэша в одной миграции - и 32-разрядной версии хэша в Другие?

Южная версия 0.8.4 - Я запускал это в совершенно новой пустой базе данных. Django версии 1.4.2

Answer 1

Выпуска был: Юг всегда смотрит в public схеме для имен ограничений, и миграция применяется в схеме, отличной public. Таким образом, неправильное совпадение.