Щоб сказати це авансом: 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
- створити тестового користувача з правами користувача
- у адміністративній панелі магазину створити дві нові групи користувачів: групу користувачів А та групу користувачів В
- в адміністративній панелі магазину, створити три різні знижки, починаючи з кількості 1
- 10% зверху на весь кошик для підсистеми 1 (так, це негативна знижка, але це лише приклад)
- 5% знижка для всіх користувачів у групі користувачів A (призначити знижку групі користувачів A)
- 20% знижки для всіх користувачів у групі користувачів B (призначити знижку групі користувачів B)
Скажімо, наш тестовий користувач належить до групи користувачів А і магазинів у підрозділі 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 вибирають` таблицю```OXID` AS `OXID`, ..., from (` table` приєднайте `relations`` t2s` on ((`t2s`.`OXMAPOBJECTID` =` таблиця```OXMAPID`))) де (`t2s`.``OXSHOPID` = 1)
Коли ми примушуємо використання основного столу, використовуємо вигляд, який не створено за допомогою об'єднання, або просто додаємо до запиту "порядок" , результат - правильний. Після того, як копалися в ній, ми виявили, що винуватцем є параметр 'block_nested_loop',. якщо це включено, ми можемо отримати неправильні набори результатів. З MySQL 5.5 все добре.
Є ще кілька місць в OXID eShop, які використовують подібну структуру запитів як клас oxDiscountList:
- oxActionList
- oxDeliveryList
- oxDeliverySetList
Але вони добре працюють з MySQL 5.6 через те, що вони обираються з іншої структуризованої таблиці перегляду або тому, що вони використовують запит з доданим 'порядком по' .
Підсумовуючи: якщо ми не використовуємо жодних знижок для OXID eShop Enterprise Edition 5.2.x під MySQL 5.6.x, все добре. Коли використовуються знижки, параметр оптимізатора MySQL для block_nested_loop повинен бути встановлений на "вимкнено", щоб бути на безпечній стороні.
