0 Пользователей и 1 Гость просматривают эту тему.
  • 18 Ответов
  • 507 Просмотров
*

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
Добрый вечер!

Сегодня была обнаружена критическая ошибка в панели администрирования списка заказов. Ошибка на данный момент возникает исключительно на MySQL 8.0.16. На предыдущих версиях MySQL, а также версиях MariaDB работа корректная.

Проблема связана с неверным использованием запросов к полю таблиц типа datetime. В результате чего, если вы решите обновиться до версии MySQL 8.0.16, вместо заказов увидите... ничего хорошего. Крайне не рекомендую.

Вопрос в целом спорный, я получил ответ от Sinisa Milivojevic с Oracle (подробнее здесь: https://bugs.mysql.com/bug.php?id=95754), они это за баг не считают и если я верно понимаю, исправлять не намерены. С одной стороны, они безусловно правы, но с другой полностью ломается принцип обратной совместимости. Скриптов и приложений с запросом типа datetime LIKE я встречал немало. Поэтому будем поглядеть.

Создана тема также на JoomShopping.com + там заодно указал пару багов, которые, надеюсь, исправят в последующих версиях.
Подробнее: https://www.joomshopping.com/forum/posts/12/13759.html?lang=ru
*

dmitry_stas

  • Легенда
  • 12997
  • 1221 / 8
спасибо что написали
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
*

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
спасибо что написали

Не за что. Да, если кто-то вдруг повторил мою ошибку и уже обновил MySQL. Тогда так:

Файл: administrator/components/com_jshopping/models/orders.php
Метод: getCountAllOrders(...) - комментируем: // $where .= " and O.order_date like '".$year."-".$month."-".$day." %'";
Метод: getAllOrders(...)- комментируем: // $where .= " and O.order_date like '".$year."-".$month."-".$day." %'";

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

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
Получил ответ от Sinisa Milivojevic (https://bugs.mysql.com/bug.php?id=95754). Цитирую:

Hi,

There is no software for which a full backward guarantee is preserved. That is why we have new versions, like 5.6, than 5.7 and now 8.0. We introduce new features, become more compliant with a standard and deprecate features that are incompatible, problematic or non-standard.

------

Если вкратце, то обратная совместимость по типу datetime сохранена не будет. Использование не по стандарту является проблемой тех, кто отклонялся от стандарта. Поэтому если вы использовали оператор LIKE для запросов к полям типа datetime - отказывайтесь от такого использования и приводите ваши программы к стандарту. Не факт, что разработчики MariaDB не пойдут по этому же пути.
*

dmitry_stas

  • Легенда
  • 12997
  • 1221 / 8
ну и хорошо :) появилась надежда что может быть наконец то у нас будет нормальный фильтр по датам От ... До..., а не та пародия которую имеем сейчас :)
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
*

sivers

  • Давно я тут
  • 800
  • 93 / 0
ну и хорошо :) появилась надежда что может быть наконец то у нас будет нормальный фильтр по датам От ... До..., а не та пародия которую имеем сейчас :)
а сейчас как?
На связи в телеге @sivers
*

dmitry_stas

  • Легенда
  • 12997
  • 1221 / 8
это трудно описать словами :) http://prntscr.com/o1g3qn
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
*

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
ну и хорошо :) появилась надежда что может быть наконец то у нас будет нормальный фильтр по датам От ... До..., а не та пародия которую имеем сейчас :)

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

Ко всему, там не все так гладко, например такой запрос: SELECT * FROM database WHERE datetime LIKE "%-%-% %"  - не работает, а такой: SELECT * FROM database WHERE datetime LIKE "201%-0%-1% 0%" - вполне адекватно работает.

Ну, и какая здесь тогда строгая типизация к полю datetime, если по прежнему, грубо говоря, регулярное выражение работает (если не пустое). А это приведет к тому, что часть кода по такой структуре будет работать, а часть нет. И та часть, что будет корректно работать всплывет когда-нибудь ни пойми когда.

Наняли вот в крупной компании удаленного работника, а он часть кода так запилил. А потом обновились и никто ничего не заметил и ущерб в итоге в миллионы, пока это поправят.

Вот вам "not a bug" от Oracle. Написал по новой. Но на особый результат не рассчитываю.
*

sivers

  • Давно я тут
  • 800
  • 93 / 0
это трудно описать словами :) http://prntscr.com/o1g3qn
Да, странное решение. Что мешало там календарь подключить?

Не менее станным кажется и поиск по полю datetime с помощью LIKE. Хоть и знал, что это поле текстовое, но использовать LIKE в голову не приходило, да и ситуацию для этого придумать не могу. Как-то обычно обходился сравнениями < и >, которые одинаково работают и с datetime, и с timestamp.
Или бывают ситуации, когда годится только LIKE?
На связи в телеге @sivers
*

dmitry_stas

  • Легенда
  • 12997
  • 1221 / 8
Или бывают ситуации, когда годится только LIKE?
ну например выбрать заказы за ноябрь всех возможных годов. хотя и тогда можно обойтись без like, а использовать month(). в любом случае такой фильтр по дате ни о чем, куда лучше и информативнее От До
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
*

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
Не менее станным кажется и поиск по полю datetime с помощью LIKE. Хоть и знал, что это поле текстовое, но использовать LIKE в голову не приходило, да и ситуацию для этого придумать не могу. Как-то обычно обходился сравнениями < и >, которые одинаково работают и с datetime, и с timestamp.
Или бывают ситуации, когда годится только LIKE?

Эти поля не текстовые. И в документации о таком их использовании ничего не сказано, это верно.
Откуда ноги растут - не знаю. Если это облегчает задачу и тем более это работает без проблем - вы это используете.
Можно считать это хаком, можно как угодно, но конструкция очень давно работала и по принципу "не усложняй себе жизнь" ею стали пользоваться. Скажем хочу выборку по январю 2012 и пишу ... LIKE "2012-01-% %", работает? Работает! А туда же еще переменные подставить, если это запрос серверу БД через ПО, тогда вообще отлично, правильно?!

Вот и наплодилось такого кода достаточна, я такое даже в СИшном Qt встречал. Это не значит, что программист дурак, просто лень поражает обходные пути, когда они есть и тем более безотказно работают (до сегодня).

Хреново то, что в Oracle это в учет не взяли. По сути да, раньше к нему относились как типу text/varchar, а теперь он вообще непонятного типа. Вроде как "strict type not string", только тогда LIKE вообще работать не должен, а он работает. Дальше, к чему может привести, выше написал.
*

sivers

  • Давно я тут
  • 800
  • 93 / 0
Эти поля не текстовые.
Да, все же это 8-байтное число.

Скажем хочу выборку по январю 2012 и пишу ... LIKE "2012-01-% %", работает? Работает!
Не проверял )) но ведь это не намного проще и не сильно короче, чем BETWEEN '2012-01-' AND '2012-02-'. Или такая конструкция с новым MySQL тоже даст сбой?
На связи в телеге @sivers
*

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
Не проверял )) но ведь это не намного проще и не сильно короче, чем BETWEEN '2012-01-' AND '2012-02-'. Или такая конструкция с новым MySQL тоже даст сбой?

Ошибку не выдает, но и возврат пустой. Вообще ваша конструкция тоже не верная (не знаю работает ли на старых версиях, так не записывал никогда). По стандарту правильно будет так:

BETWEEN CAST('2012-01-01 00:00:00' AS DATETIME) AND CAST('2012-02-29 23:59:59' AS DATETIME)

или

BETWEEN CAST('2012-01-01' AS DATE) AND CAST('2012-02-29' AS DATE)

в зависимости от того к какому типу поля обращаетесь. Причем, настоятельно рекомендуется использовать функцию CAST для явного приведения к типу.
*

sivers

  • Давно я тут
  • 800
  • 93 / 0
Причем, настоятельно рекомендуется использовать функцию CAST для явного приведения к типу.
Не поспоришь. С тИпами уже бывали прецеденты ))
На связи в телеге @sivers
*

ProtectYourSite

  • Завсегдатай
  • 1926
  • 104 / 4
  • Безопасность вебсайтов
Причем, настоятельно рекомендуется использовать функцию CAST для явного приведения к типу.
С этим можно поспорить, с CAST индексы работать не будут.
*

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
С этим можно поспорить, с CAST индексы работать не будут.

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

Может вы подразумевали CAST(ПОЛЕ_ТАБЛИЦЫ AS ТИП), тогда, да, функция будет вызываться для каждого значения в цикле.  Но это только в теории, таким образом CAST не должен работать вообще, а MySQL должна вернуть исключение об ошибке. По крайней мере, я такого использования CAST не встречал ни разу .
*

Capere

  • Новичок
  • 1
  • 1 / 0
Специально зарегистрировалась, чтобы поблагодарить.
Никак не могла найти, в каком конкретно месте не нравится запрос.
*

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
Специально зарегистрировалась, чтобы поблагодарить.
Никак не могла найти, в каком конкретно месте не нравится запрос.

Разработчики, к сожалению, не спешат с обновлениями. Из последних моих багрепортов исправили лишь модуль Latest Products (не тестировал, но код смотрел, модуль последней версии должен работать хорошо).

P.S. С форумом не раньше зимы буду осваиваться, сейчас времени хватает только на семью и работу. Если кому-то не смогу ответить, значит времени не просто нет, а совсем нет)
*

D. Tkachenko

  • Осваиваюсь на форуме
  • 30
  • 4 / 0
В Joomla тоже баг был, кстати, связанный с MySQL 8.

Цитировать
Bug fixes and Improvements
Custom Fields: Fix language strings/unknown columns/sorting #25476
Creating categories on the fly with numbers #25024
Fix database schema checker for MySQL 8 #25658
Tree sorting in templates file tree #25792
Improved PHP 7.4 compatibility #25784

Рекомендую не забыть обновиться до версии  3.9.11.
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться
 

Второе описание для категории не сохраняется в последнем JoomShopping

Автор hello-andrew

Ответов: 17
Просмотров: 374
Последний ответ 15.10.2019, 23:33:12
от hello-andrew
Привязать плагин галереи к JoomShopping

Автор ewgenij05

Ответов: 24
Просмотров: 4619
Последний ответ 11.10.2019, 16:16:21
от musstudent
Ошибка 500 - Макет registermail не найден - при регистрации [Решено]

Автор jesus

Ответов: 2
Просмотров: 1457
Последний ответ 10.10.2019, 22:39:42
от surho
Обновление страниц JoomShopping

Автор shane

Ответов: 1
Просмотров: 131
Последний ответ 20.09.2019, 20:30:18
от shane
Не работает меню-аккордеон c JoomShopping

Автор surho

Ответов: 5
Просмотров: 127
Последний ответ 20.09.2019, 16:07:18
от surho