Django.db.utils.OperationalError 3780 - Ссылающийся столбец и ссылающийся столбец "id" в ограничении внешнего ключа несовместимы
После прочтения этого django.db.utils.OperationalError: 3780 Ссылающийся столбец и ссылающийся столбец несовместимы и SQLSTATE[HY000]: Общая ошибка: 3780 Ссылающийся столбец 'user_id' и ссылающийся столбец 'id' во внешнем ключе несовместимы
У меня есть две модели в Django 3.2.16, объявленные в разных приложениях, это давний проект, который начался в Django 2.2 и был обновлен с течением времени.
Вот два класса моделей:
from city_search.models
class Città(models.Model):
nome = models.CharField(max_length = 50, db_index = True)
def __str__(self):
return "{} - {}".format(self.nome,self.regione)
provincia = models.ForeignKey(Provincia, models.SET_NULL, blank=True,null=True)
capoluogo = models.BooleanField(default=False)
regione = models.ForeignKey(Regione, models.SET_NULL, blank=True,null=True, related_name='comuni')
slug = models.SlugField(null=True)
latlng = LocationField(null=True,map_attrs={"center": [2.149123103826298,41.39496092463892], "zoom":10})
вместо этого из eventos.models, который я разрабатываю
from schedule.models import events
class Manifestazione(events.Event):
ciudad = models.ForeignKey('city_search.Città', on_delete=models.CASCADE, verbose_name='Ciudad', related_name='manifestaciones', blank=False, null=False)
Миграция последней модели не удается со следующей ошибкой:
django.db.utils.OperationalError: (3780, "Referencing column 'ciudad_id' and referenced column 'id' in foreign key constraint 'eventos_manifestazio_ciudad_id_74f49286_fk_city_sear' are incompatible.")
эти два объявления моделей транслируются в следующие таблицы MySQL (вторая создана лишь частично в результате ошибочной миграции)
mysql> describe city_search_città;
+--------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+-------------+------+-----+---------+----------------+
| id | int | NO | PRI | NULL | auto_increment |
| nome | varchar(50) | NO | MUL | NULL | |
| provincia_id | int | YES | MUL | NULL | |
| capoluogo | tinyint(1) | NO | | NULL | |
| regione_id | int | YES | MUL | NULL | |
| slug | varchar(50) | YES | MUL | NULL | |
| latlng | varchar(63) | YES | MUL | NULL | |
+--------------+-------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)
and
После прочтения этого django.db.utils.OperationalError: 3780 Ссылающийся столбец и ссылающийся столбец несовместимы и SQLSTATE[HY000]: Общая ошибка: 3780 Ссылающийся столбец 'user_id' и ссылающийся столбец 'id' во внешнем ключе несовместимы
У меня есть две модели в Django 3.2.16, объявленные в разных приложениях, это давний проект, который начался в Django 2.2 и был обновлен с течением времени.
Вот два класса моделей:
from city_search.models
class Città(models.Model):
nome = models.CharField(max_length = 50, db_index = True)
def __str__(self):
return "{} - {}".format(self.nome,self.regione)
provincia = models.ForeignKey(Provincia, models.SET_NULL, blank=True,null=True) #con varazioni confini delle province in futuro, non si perdono i comuni
capoluogo = models.BooleanField(default=False)
regione = models.ForeignKey(Regione, models.SET_NULL, blank=True,null=True, related_name='comuni')
slug = models.SlugField(null=True)
latlng = LocationField(null=True,map_attrs={"center": [2.149123103826298,41.39496092463892], "zoom":10})
вместо этого из eventos.models, который я разрабатываю
from schedule.models import events
class Manifestazione(events.Event):
ciudad = models.ForeignKey('city_search.Città', on_delete=models.CASCADE, verbose_name='Ciudad', related_name='manifestaciones', blank=False, null=False)
Миграция последней модели не удается со следующей ошибкой:
django.db.utils.OperationalError: (3780, "Referencing column 'ciudad_id' and referenced column 'id' in foreign key constraint 'eventos_manifestazio_ciudad_id_74f49286_fk_city_sear' are incompatible.")
эти два объявления моделей транслируются в следующие таблицы MySQL (вторая создана лишь частично в результате ошибочной миграции)
mysql> describe city_search_città;
+--------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+-------------+------+-----+---------+----------------+
| id | int | NO | PRI | NULL | auto_increment |
| nome | varchar(50) | NO | MUL | NULL | |
| provincia_id | int | YES | MUL | NULL | |
| capoluogo | tinyint(1) | NO | | NULL | |
| regione_id | int | YES | MUL | NULL | |
| slug | varchar(50) | YES | MUL | NULL | |
| latlng | varchar(63) | YES | MUL | NULL | |
+--------------+-------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)
и
mysql> describe eventos_manifestazione;
+--------------+--------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------+--------+------+-----+---------+-------+
| event_ptr_id | int | NO | PRI | NULL | |
| ciudad_id | bigint | NO | | NULL | |
+--------------+--------+------+-----+---------+-------+
2 rows in set (0.00 sec)
Теперь я абсолютно понимаю, что int
и bigint
- это большая разница. Однако я уже пытался установить DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'
в settings.py до создания миграций и после миграции, безрезультатно.
Согласно Django Docs on automatic primary key fields я также мог попробовать использовать AppConfig, поэтому я также отредактировал eventos/apps.py следующим образом и позже выполнил миграцию
class EventosConfig(AppConfig):
default_auto_field = 'django.db.models.AutoField'
name = 'eventos'
, который тоже не сработал. Я по-прежнему получаю те же схемы таблиц, что и выше.
Поскольку я также читал о возможной проблеме с коллацией, я сравню коллации таблиц ниже:
mysql> select column_name, COLLATION_NAME, CHARACTER_SET_NAME from information_schema.`COLUMNS` where table_name = "city_search_città";
+--------------+-------------------+--------------------+
| COLUMN_NAME | COLLATION_NAME | CHARACTER_SET_NAME |
+--------------+-------------------+--------------------+
| id | NULL | NULL |
| nome | latin1_swedish_ci | latin1 |
| provincia_id | NULL | NULL |
| capoluogo | NULL | NULL |
| regione_id | NULL | NULL |
| slug | latin1_swedish_ci | latin1 |
| latlng | latin1_swedish_ci | latin1 |
+--------------+-------------------+--------------------+
7 rows in set (0.00 sec)
и
mysql> select column_name, COLLATION_NAME, CHARACTER_SET_NAME from information_schema.`COLUMNS` where table_name = "eventos_manifestazione";
+--------------+----------------+--------------------+
| COLUMN_NAME | COLLATION_NAME | CHARACTER_SET_NAME |
+--------------+----------------+--------------------+
| event_ptr_id | NULL | NULL |
| ciudad_id | NULL | NULL |
+--------------+----------------+--------------------+
2 rows in set (0.01 sec)
Моя гипотеза
- более вероятно, что виновата разница
int
иbigint
и я не могу из-за какой-то ошибки или странной причины, что миграции игнорируют мое желание перейти наint
в качестве автоматического поля первичного ключа? - Связано ли это с некоторой разницей в использовании этих настроек, когда речь идет о внешних ключах?
- Или вы считаете, что это может быть связано с разницей в collation?
Я не могу завершить правильную миграцию
Похоже, текст ошибки предупреждал о неправильной таблице. Все заработало, если добавить DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'
в settings.py и сделать новые миграции по всему проекту, которые включали некоторые изменения в полях модели третьего приложения, где действительно models.AutoField
было установлено на id
поля/столбцы.
Это третье приложение и то, которое я разрабатываю, не связаны напрямую через ForeignKey, я не понимаю, где здесь связь, хотя ошибка появилась после того, как я создал модели, о которых я упоминал в этой теме. Поэтому, честно говоря, я не очень понимаю, почему это сработало или какое отношение эти третьи модели могут иметь к новому приложению, которое я добавляю в проект. Я бы очень хотел узнать, если кто-то понимает больше.