User ban expire date - Githubissues

Alex300 commented 1 month ago

[RU]

У нас есть и используется поле в БД users.user_banexpire для хранения даты/времени истечения бана пользователя. Но в modules/users/inc/users.edit.php не генерится тег для вывода этого поля на форму редактирования пользователя. Только импорт этого знаяения как INT и сохранение в БД.

Нужно:

~~Заменить тип поля в БД с INT на DATETIME DEFAULT NULL~~ (Пока решили оставить INT)
Сделать элемент формы для редактирования этого поля (формат дата/время)
~~места где оно используется - учесть что в этом поле больше не INT.~~

seditio commented 1 month ago

Предлагаю добавить еще поле с датой добавления IP / email и сортировать по убыванию этой даты. Иначе добавил запись, а она где-то на второй или третьей странице оказывается. По мере возможности, поиск и сортировка бы не помешала. И еще один момент: может быть имеет смысл к действиям (обновить и удалить) добавить паузу. Это помогло бы "ставить на проверку" спамерские айпишники вместо удаления и необходимости где-то там помечать подозрительный адрес.

Alex300 commented 1 month ago

Тут я имел ввиду редактирование пользователей, где можно добавлять пользователей в группу banned. Там бан реализован на уровне системы. Но и плагин banlist тоже надо бы доработать.

Dayver commented 1 month ago

Заменить тип поля в БД с INT на DATETIME DEFAULT NULL

места где оно используется - учесть что в этом поле больше не INT.

А какая логика в этих действиях? Везде в движке для дат преимущественно используется INT

Alex300 commented 1 month ago

Удобство использования. Например написание прямых запросов к БД - не надо конвертить дату в INT чтобы вставить в запрос. И при просмотре данных в таблице удобнее видеть даты а не целые числа. Да и отлаживать запросы удобнее с текстовым представлением даты.

К тому же, с типом INT не работают специализированные функции: https://dev.mysql.com/doc/refman/8.4/en/date-and-time-functions.html

На PHP строковое представление даты также легко сортируется, сравнивается и т.д. И для отладки через XDebug проще когда видишь дату а не INT.

При этом нет потерь в скорости.

Вообще думаю отказаться от использования INT для хранения дат. Пока в новом коде, и там где не сломается совместимость.

Dayver commented 1 month ago

Удобство использования...Вообще думаю отказаться от использования INT для хранения дат. Пока в новом коде, и там где не сломается совместимость.

Прочитал весь комментарий но увидел главенствующее - "удобство". То есть в угоду банальному удобству отказываться от более-менее за года стандартизированного подхода, при этом не имея других значимых плюсов? Что бы опять получить кашу, теперь и в структуре (как это сейчас с стилем кодирования), пусть даже в перспективе когда-то это изменится но будет ли стоит это затраченных усилий? Сравним

TIMESTAM vs DATETIME:

часовые пояса - TIMESTAM Интернационализацию хотим развивать но при этом работу с часовыми поясами усложняем.
занимаемое место - TIMESTAM Да, в новом php разрыв уменьшен но все же он есть потому на больших массивах данных это ощутимо. То есть постепенно начинаем из преимуществ движка из фразы "Быстрый и легкий" вычёркивать "лёгкий".
централизированная обработка - TIMESTAM Поскольку у нас типа фреймворк то везде стандартный int записали\прочитали как есть в любой базе, а остальные обработки в php. Из выше указанного прочитал что для удобства переносим обработку дат в mysql (тезис про специализированные mysql функции), а значит уходим от общей концепции?
скорость - TIMESTAM Честно не приходилось заморачиваться и сравнивать (банально потому что используемый TIMESTAM устраивает) но интернеты пишут что DATETIME выигрывает в скорости в редких ситуациях (специфических запросах). Даже если текущая ситуация изменилась в современных условиях то явно не в сторону перевеса DATETIME, а в сторону паритета.
специфические запросы - TIMESTAM \ DATETIME Тут уже от специфики в одних случаях сильно выигрывает один тип, а в других другой. Потому глобально скажем так - ничья.
удобство просмотра - DATETIME Тут бесспорно DATETIME но если использовать инструменты помощники (для просмотра базы давно) то это уже и не такая уж и проблема с TIMESTAM. Разве что с XDebug действительно это безальтернативно
до 1970 - DATETIME Вообще кому-то это нужно вообще?

То есть если бы систему движка делали с нуля и стоял холивар "какой тип дат" то простыми словами он бы описывался вопросом - "Или производительность конечного продукта или удобство в процессе разработки?" то руководствуясь концепцией думаю производительность победила бы (уже не помню но по моему сейчас timestam это внутренний стандарт именно поэтому).

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

Или вот даже вопрос удобства и понятности кода новичку - будет ли удобно и понятно если одни столбцы DATETIME а другие TIMESTAM ? Стандартизированность всегда лучше. Ведь как оказалось стратегия затрагивает не только конкретно колонку user_banexpire, потому пол дела если каша будет во время переходного периода другое дело если ведущий разработчик пропадёт (как это уже не раз бывало с движком ... причём в некоторых случая уже точно никто не вставлял палки в колёса но человек все равно пропадал) и все так и зависнет - уж простите но этот вопрос тоже очень беспокоит.