Скажем прямо: OXID eShop Enterprise Edition 5.2.x почти отлично работает с MySQl 5.6, но есть небольшая неприятная ошибка MySQL ( # 79203 ) что вам лучше знать. На это не влияют OXID eShop Professional и Community Edition.

Мы впервые столкнулись с несоответствиями с применением скидок при запуске OXID eShop Enterprise Edition 5.2.6 на Debian GNU / Linux 7.8 (wheezy) с PHP 5.6.15 и MySQL 5.6.25.

Пример:

• настроить OXID eShop Enterprise Edition 5.2.x
• создать тестового пользователя с правами пользователя
• в панели администратора магазина создайте две новые группы пользователей: группу пользователей A и группу пользователей B
• В админ-панели магазина создайте три разных скидки, начиная с количества 1
• 10% от всей корзины для магазина 1 (да, это отрицательная скидка, но это только пример)
• Скидка 5% для всех пользователей в группе пользователей А (назначить скидку для группы пользователей А)
• Скидка 20% для всех пользователей в группе B (назначьте скидку для группы B)

Скажем, наш тестовый пользователь относится к группе пользователей A и совершает покупки в подшопе 1. В этом случае он должен получить 10% надбавки для подшопа и 5% скидки для своей группы пользователей.

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

Похоже, оптимизатор MySQL 5.6 имеет проблемы с определенным типом запроса, когда представления
вовлечены. Класс oxDiscountList выполняет запрос структуры

выберите viewtable.oxid из viewtable где (выберите if (EXISTS ('таблица отношений поиска плюс связанная таблица для любых соответствующих строк, содержащих viewtable.oxid. Запись в связанной таблице должна существовать.'), EXISTS ('выполнить подробный поиск в таблице отношений для строк условия сопоставления, содержащие viewtable.oxid '), 1) && if (EXISTS (' искать другую таблицу отношений плюс другую связанную таблицу для любых соответствующих строк, содержащих viewtable.oxid. Запись в другой связанной таблице должна существовать. '), EXISTS (' do detail поиск в другой таблице отношений для строк, соответствующих условиям, содержащим viewtable.oxid '), 1) ... и т. д.)

на вид создан как

CREATE ... VIEW `viewtable` AS select` table` .OXID` AS `OXID`, ..., from (` table` join `relations`` t2s` on ((`t2s`.`OXMAPOBJECTID` =` table` .OXMAPID`))) где (`t2s` .OXSHOPID` = 1)

Когда мы принудительно используем базовую таблицу, используем представление, созданное не с помощью объединения, или просто добавляем в запрос 'order by' , набор результатов будет правильным. Немного покопавшись в этом, мы обнаружили, что виновником является установка для block_nested_loop . если это включено, мы можем получить неправильные наборы результатов. С MySQL 5.5 все хорошо.

В OXID eShop есть еще несколько мест, в которых используется структура запроса, аналогичная классу oxDiscountList:

• oxActionList
• oxDeliveryList
• oxDeliverySetList

Но они отлично работают с MySQL 5.6 либо из-за выбора из таблицы с разной структурой представления, либо из-за того, что они используют запрос с добавленным 'order by' .

Подводя итог: пока мы не используем какие-либо скидки на OXID eShop Enterprise Edition 5.2.x под MySQL 5.6.x, все хорошо. При использовании скидок настройку оптимизатора MySQL для block_nested_loop следует отключить, чтобы обеспечить безопасность.

Похожие