Подготовить БД к хранению времени с микросекундами

[Denis_N]

Подготовить БД к хранению времени с микросекундами

Для реализации #1219 нужно, чтобы поля времени в БД могли хранить дробную часть секунд. Сейчас, по проверке локальной схемы, поля имеют тип без микросекунд:

• history.date — datetime
• orders.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);

[alx]

Replying to Denis_N:

Подготовить БД к хранению времени с микросекундами

??? А сейчас она разве не готова?

[Denis_N]

Replying to alx:

??? А сейчас она разве не готова?

Сама СУБД действительно поддерживает хранение микросекунд в DATETIME.

Но в данном случае речь про конкретные поля в нашей схеме. Сейчас они объявлены как DATETIME без указания точности:

history.date — DATETIME
orders.datetime — DATETIME

Для MySQL/MariaDB это соответствует точности 0 знаков дробной части секунды. То есть если в такое поле записать NOW(6), дробная часть секунд сохранена не будет.

Чтобы #1219 имел смысл, нужно две части:

1. В схеме БД изменить поля на DATETIME(6).
2. В коде заменить запись времени с NOW() на NOW(6) там, где нужна повышенная точность.

Именно поэтому был создан #1507: не потому что СУБД в принципе не умеет микросекунды, а потому что текущая схема конкретных полей их не сохраняет.

[san]

In 618/base:

В history и products столбец времени расширен до datetime(6). Closes #1507
Добавлены таблицы учёта изделий без серийного номера stock_containers, stock_container_history
В users добавлено поле token - токен для авторизации по QR-коду бейджика и добавлена таблица security_counters для учёта количества аутентификаций.

[alx]

Replying to san:

В users добавлено поле token - токен для авторизации по QR-коду бейджика

А это что за авторизация такая?

[Denis_N]

Replying to alx:

А это что за авторизация такая?

Нужна для работы со складом. Каждому пользователю печатается бейджик с qr-кодом, польователь заходит на склад и чтобы система его авторизовала, ему нужно отсканировать свой бейджик где в qr-код зашифрован токен пользователя.

Это нужно, чтобы пользователь не авторизовывался вручную для работы со складом.

[alx]

Replying to Denis_N:

Каждому пользователю печатается бейджик с qr-кодом, польователь заходит на склад и чтобы система его авторизовала,

Авторизовала на что?

ему нужно отсканировать свой бейджик где в qr-код зашифрован токен пользователя.
Это нужно, чтобы пользователь не авторизовывался вручную для работы со складом.

Хм... А вот это, что ты только что описал - разве не "вручную"? :)

[Denis_N]

Replying to alx:

Replying to Denis_N:

Каждому пользователю печатается бейджик с qr-кодом, польователь заходит на склад и чтобы система его авторизовала,

Авторизовала на что?

ему нужно отсканировать свой бейджик где в qr-код зашифрован токен пользователя.
Это нужно, чтобы пользователь не авторизовывался вручную для работы со складом.

Хм... А вот это, что ты только что описал - разве не "вручную"? :)

Под “авторизацией” здесь имелся в виду не вход в систему целиком, а допуск к работе в интерфейсе склада stock_scan на общем складском терминале.

Сценарий такой: сотрудник подходит к терминалу, сканирует бейдж, система по users.token находит пользователя, проверяет его права на работу со складом и открывает складскую сессию уже от его имени. Это нужно, чтобы действия в складском интерфейсе были привязаны к конкретному сотруднику и не приходилось каждый раз вводить логин/пароль на клавиатуре.

То есть да, действие со стороны пользователя остаётся, но это не “ручная авторизация по логину/паролю”, а быстрый вход одним сканированием бейджа.

security_counters при этом нужна только как счётчик неудачных сканов/попыток, чтобы не было бесконечного перебора токенов.

[alx]

Replying to Denis_N:

Под “авторизацией” здесь имелся в виду не вход в систему целиком, а допуск к работе в интерфейсе склада stock_scan на общем складском терминале.

Подожди... Если речь идет о работе в системе учета продукции АДС, то там авторизация выполняется при каждом запросе чисто автоматически (без какого-либо участия пользователя) - путем проверки значения поля root в таблице users. Разве нет? Почему же сейчас потребовалось дополнительное поле token и сканирование бейджа?

Сценарий такой: сотрудник подходит и берет сканер подключенный к ноутбуку, сканирует бейдж, система по users.token находит пользователя, проверяет его права на работу со складом и открывает складскую сессию уже от его имени. Это нужно, чтобы действия в складском интерфейсе были привязаны к конкретному сотруднику и не приходилось каждый раз вводить логин/пароль на клавиатуре.

Подожди... Ты хочешь сказать, что пользователь работает в системе без аутентификации? А хорошо ли это, что неаутентифицированный пользователь может делать изменения в БД от чьего-то имени?

То есть да, действие со стороны пользователя остаётся, но это не “ручная авторизация по логину/паролю”, а быстрый вход одним сканированием бейджа.

??? Процедура, при которой вводится логин и пароль - это не авторизация, а аутентификация. Ты не путаешь ли их? Прости, но по-моему у тебя какая-то путаница в голове...