Opened 3 weeks ago
Last modified 2 weeks ago
#1507 assigned дефект
Подготовить БД к хранению времени с микросекундами
| Reported by: | Denis_N | Owned by: | san |
|---|---|---|---|
| Priority: | minor | Component: | Разное и всякое |
| Keywords: | Cc: |
Description (last modified by )
Подготовить БД к хранению времени с микросекундами
Для реализации #1219 нужно, чтобы поля времени в БД могли хранить дробную часть секунд. Сейчас, по проверке локальной схемы, поля имеют тип без микросекунд:
history.date—datetimeorders.datetime—datetime
Из-за этого даже при замене NOW() на NOW(6) микросекунды не будут сохраняться.
Проверить можно запросом:
SHOW FULL COLUMNS FROM history LIKE 'date'; SHOW FULL COLUMNS FROM orders LIKE 'datetime';
Предлагается изменить типы полей:
sql
ALTER TABLE history MODIFY `date` DATETIME(6); ALTER TABLE orders MODIFY `datetime` DATETIME(6) DEFAULT CURRENT_TIMESTAMP(6);
Change History (5)
comment:1 by , 3 weeks ago
| Description: | modified (diff) |
|---|
follow-up: 4 comment:2 by , 3 weeks ago
comment:4 by , 2 weeks ago
Replying to alx:
??? А сейчас она разве не готова?
Сама СУБД действительно поддерживает хранение микросекунд в DATETIME.
Но в данном случае речь про конкретные поля в нашей схеме. Сейчас они объявлены как DATETIME без указания точности:
history.date — DATETIME
orders.datetime — DATETIME
Для MySQL/MariaDB это соответствует точности 0 знаков дробной части секунды. То есть если в такое поле записать NOW(6), дробная часть секунд сохранена не будет.
Чтобы #1219 имел смысл, нужно две части:
- В схеме БД изменить поля на DATETIME(6).
- В коде заменить запись времени с NOW() на NOW(6) там, где нужна повышенная точность.
Именно поэтому был создан #1507: не потому что СУБД в принципе не умеет микросекунды, а потому что текущая схема конкретных полей их не сохраняет.
comment:5 by , 2 weeks ago
| Description: | modified (diff) |
|---|
![[MC-04 logo]](/mc-04/chrome/site/logo.png)
Replying to Denis_N:
??? А сейчас она разве не готова?