У нас есть соглашение об именах camelCase во всем, что мы делаем - от таблиц базы данных до свойств объектов, столбцов, индексов базы данных и ограничений.
Мы работаем с этими соглашениями уже два месяца в новом проекте, и все шло хорошо, когда вчера вечером все отношения касались только одной из наших 6 баз данных, преобразованных из camelCase в нижний регистр. Важно отметить, что только преобразованные ограничения - сами индексы остались camelCase.
Итак, если бы у нас был столбец с именем someColumn и другой, someTable.otherColumn, то он пошел от этого:
someColumn => someTable.otherColumn ON DELETE CASCADE ON UPDATE CASCADE
:
someColumn => someTable.otherColumn ON DELETE CASCADE ON UPDATE CASCADE
Что может быть причиной этого? Мы не смогли воспроизвести эту проблему - мы попытались изменить случайное ограничение, чтобы увидеть, изменит ли он их все, и мы попытались повторно импортировать структуру, и все прошло отлично, сохранив CamelCase от импорта.
Мы работаем над OSX и развертываем CentOS.
Изменить: один разработчик использует нечувствительный к регистру OSX. Он попытался повторно импортировать базу данных из экспорта на своей собственной машине, и все было в порядке: импорт дампа с нечувствительной к регистру машины в чувствительный к регистру CentOS не нарушал ситуацию. Перезапуск mysqld также не смог воспроизвести эту ошибку. Все настройки mysql с нижним регистром отключены. На сегодняшний день мы не смогли повторить это.
Edit2: Обратите внимание, что это произошло только на нашем сервере разработки CentOS - разработчик, который использует нечувствительную к регистру ОС, импортировал свою базу данных раньше, чем другие, которые находятся на чувствительных к регистру системах, и все было в порядке каждый раз.
Отчет об ошибке # 55897 предполагает, что это по дизайну и документировано под Ограничения на InnoDB Таблица:
В Windows
InnoDBвсегда хранит имена базы данных и таблиц внутри в нижнем регистре.
См. также Нечувствительные к регистру имена ограничений в MySQL.
Вам нужно изучить две переменные в MySQL на сервере OSX my.cnf
Согласно документации MySQL на lower_case_table_names
Вы не должны устанавливать эту переменную в 0, если вы используете MySQL в системе с именами без учета регистра (например, Windows или Mac OS X). Если вы установите эту переменную на 0 в такой системе и получите доступ к табличным именам MyISAM с использованием разных почтовых ящиков, это может привести к повреждению индекса. В Windows значение по умолчанию равно 1. В Mac OS X значение по умолчанию равно 2.
Несмотря на то, что вышеприведенная выдержка относится к MyISAM, можно только догадываться, какие хопы MySQL перескакивают с помощью InnoDB, учитывая значение по умолчанию lower_case_table_names в OSX. В свете этого, если у вас есть lower_case_table_names=0 или lower_case_table_names=1 в вашем OSX my.cnf, mysqld, вероятно, немного запутался.
Поэтому не удивляйтесь, если какие-либо mysqldumps с сервера OSX, перемещенные в CentOS, не меняют ситуацию.
Это, скорее всего, то, с чем вы сейчас сражаетесь.