MyTetra Share
Делитесь знаниями!
MySQL strict mode - проблема проверки на DEFAULT значения
Время создания: 13.07.2018 15:31
Текстовые метки: mysql strict mode
Раздел: MySQL

После переезда с версии MySQL 5.5.13 на 5.6.10 стали вылезать странные грабли.


Симптом №1:


Caused by: java.sql.SQLException: Incorrect string value: '\xE6\xAF\x94FOX...' for column 'parameter_value' at row 4

at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1078)

at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4190)


Симптом №2:


Data truncation: Data too long for column 'channel' at row 1

org.hibernate.exception.DataException: could not execute native bulk manipulation query


Так как "раньше всё работало" и в код приложения никто изменений не вносил, закралось подозрение, что новый mysql работает в каком-то более строгом режиме. Гугление вывело на глобальную переменную sql_mode.


mysql> SHOW global variables LIKE 'sql_mode';

+--------------------------+--------------------------------------------+

| Variable_name | Value |

+--------------------------+--------------------------------------------+

| sql_mode | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |

+--------------------------+--------------------------------------------+


Читаем официальное руководство и видим:


STRICT_TRANS_TABLES

If a value could not be inserted as given into a transactional table, abort the statement. For a nontransactional table, abort the statement if the value occurs in a single-row statement or the first row of a multiple-row statement.


На основе этой инфы приходит в голову мысль, что надо этот режим STRICT_TRANS_TABLES попробовать отключить:


mysql> SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';

mysql> SHOW global variables LIKE 'sql_mode';

+---------------+------------------------+

| Variable_name | Value |

+---------------+------------------------+

| sql_mode | NO_ENGINE_SUBSTITUTION |

+---------------+------------------------+


И таки да, после этого запросы, ранее выполнявшиеся с ошибками, стали отрабатывать нормально, как и было на версии 5.5.13. Чтобы сохранить изменения навсегда, в /etc/my.cnf я добавил в секции [mysqld]


sql-mode="NO_ENGINE_SUBSTITUTION"


Однако далее меня ждала еще одна засада – после рестарта mysql-сервера я опять увидел знакомую картину, несмотря на внесенные в /etc/my.cnf изменения:


mysql> show global variables like 'sql_mode';

+--------------------------+--------------------------------------------+

| Variable_name | Value |

+--------------------------+--------------------------------------------+

| sql_mode | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |

+--------------------------+--------------------------------------------+


Это было непостижимо и удивительно. Я уже и еще раз проверил hostname у сервера, дабы убедиться, что всё ранее сделанное происходило именно на том сервере, где и должно было происходить. Почесав пару минут репу, решил проверить наличие других конфигов mysql-сервера в системе. И таки нашёл один такой в /usr/my.cnf:


$ cat /usr/my.cnf | grep -vE "^#" | sed -r "/^$/ d"

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES


Вот он, вражеский конфиг, который переопределял моё значение sql_mode! Что самое прикольное, больше ничего в этом конфиге не было. Как будто его специально всунули, чтобы добавить мне головняка. После удаления файла /usr/my.cnf и рестарта mysql-сервера я уже раз и навсегда получил возможность наслаждаться значением sql_mode без STRICT_TRANS_TABLES.

 
MyTetra Share v.0.53
Яндекс индекс цитирования