read_write_info (
user_id int comment 'ID пользователя',
read_timestamp timestamp comment 'Дата чтения',
write_timestamp timestamp comment 'Дата изменения');
Далее заполнил ее:
insert into
read_write_info (user_id)
values
(1), (2), (3);
В итоге в колонке read_timestamp оказался timestamp исполнения 2-го скрипта, а в колонке write_timestamp — 0:00.
Почему такая разница?
Видимо, в таблицэ записаны какие-то дефолты. Или триггеры.
Так и базу и таблицу создал я и с нуля. Откуда там взяться этой асимметрии?
Как бы если ты не заполняешь эти поля то там ничего не должно быть
а что такое второй скрипт? как именно себя должен вести timestamp без указания дефолтов? всё тут прочитали? https://dev.mysql.com/doc/refman/8.0/en/timestamp-initialization.html
Кто ж тебя знает?
Поскольку никаких данных я туда не вношу, то ожидал увидеть там Null. Я бы не удивился увидеть там текущий таймштамп. И то, и другое вполне логично. Но я удивляюсь, что абсолютно одинаковые при создании и заполнении колонки оказались с разным содержанием.
Так у тебя поля нотнул К тому же Time Stamp тип наверное имеет особую семантику и это поле автоматически меняется при любом изменении
Это поле автоматически меняется при любом изменении записи
Ещё Я помню что такое поле в одной таблице должно быть только одно, может быть у тебя именно с этим проблемы прочитай в документации про этот тип данных особый и уникальный
Вообще такие типы данных предназначаются для контроля изменения записей другими пользователями при так называемом оптимистическом блокировании записей. И кстати оно никак не связано со временем по идее это совсем не то что тебе нужно тебе нужно дейтайм плюс либо триггера либо добавление этих полей в инферты и апдейты с указанием времени
Прочитал, что первая timestamp колонка в таблице автоматически получает соответствующий атрибут! Теперь понятно.
Так оно и нужно, только контроль будет на уровне самого приложения.
Explicit_defaults_for_timestamp=off только если. Но это наркоманство всё.
Обсуждают сегодня