Все наши ограничения MySQL прошли в нижнем регистре. Что может вызвать это?

У нас есть соглашение об именах 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 - разработчик, который использует нечувствительную к регистру ОС, импортировал свою базу данных раньше, чем другие, которые находятся на чувствительных к регистру системах, и все было в порядке каждый раз.

Ответ 1

Отчет об ошибке # 55897 предполагает, что это по дизайну и документировано под Ограничения на InnoDB Таблица:

В Windows InnoDB всегда хранит имена базы данных и таблиц внутри в нижнем регистре.

См. также Нечувствительные к регистру имена ограничений в MySQL.

Ответ 2

Вам нужно изучить две переменные в 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, не меняют ситуацию.

Это, скорее всего, то, с чем вы сейчас сражаетесь.