Aby powiedzieć to z góry: OXID eShop Enterprise Edition 5.2.x działa prawie dobrze z MySQl 5.6, ale jest trochę nieprzyjemny błąd MySQL ( # 79203 ), o których lepiej być świadomym. OXID eShop Professional i Community Edition nie mają na to wpływu.
Po raz pierwszy napotkaliśmy niespójności w stosowaniu rabatów podczas uruchamiania OXID eShop Enterprise Edition 5.2.6 w Debianie GNU / Linux 7.8 (wheezy) z PHP 5.6.15 i MySQL 5.6.25.
Przykład:
- skonfigurować OXID eShop Enterprise Edition 5.2.x
- utwórz użytkownika testowego z prawami użytkownika
- w panelu administratora sklepu utwórz dwie nowe grupy użytkowników: grupa użytkowników A i grupa użytkowników B
- w panelu administratora sklepu utwórz trzy różne zniżki, zaczynając od ilości 1
- 10% na cały koszyk na podkarpacie 1 (tak, to rabat ujemny, ale to tylko przykład)
- 5% zniżki dla wszystkich użytkowników w grupie użytkowników A (przypisanie rabatu do grupy użytkowników A)
- 20% zniżki dla wszystkich użytkowników w grupie użytkowników B (przypisanie rabatu do grupy użytkowników B)
Powiedzmy, że nasz użytkownik testowy należy do grupy użytkowników A i sklepów w podkarpacie 1. W takim przypadku powinien otrzymać 10% dopłaty do subskrybcji i 5% zniżki dla swojej grupy użytkowników.
W rezultacie na początku były wszystkie trzy rabaty lub nie zastosowano żadnych, trzy z nich, gdy
jednocześnie jesteś zalogowany jako administrator na innej karcie i wybierz przegląd rabatów. Oznacza to, że w naszym przypadku rabaty nie są stosowane prawidłowo. Przy tej samej konfiguracji, ale zainstalowanej MySQL 5.5, wszystkie rabaty są stosowane poprawnie.
Wygląda na to, że optymalizator MySQL 5.6 ma problemy z konkretnym rodzajem zapytania podczas wyświetlania
są zamieszani. Klasa oxDiscountList wykonuje zapytanie o strukturę
wybierz viewtable.oxid z viewtable gdzie (wybierz if (EXISTS ('tabela relacji wyszukiwania plus powiązana tabela dla wszystkich pasujących wierszy zawierających viewtable.oxid. Wpis w powiązanej tabeli musi istnieć.'), EXISTS ('wykonaj wyszukiwanie szczegółów w tabeli relacji dla wierszy pasujące warunki zawierające viewtable.oxid '), 1) && if (EXISTS (' przeszukaj inną tabelę relacji plus inną powiązaną tabelę dla pasujących wierszy zawierających viewtable.oxid. Wpis w innej powiązanej tabeli musi istnieć. ”), EXISTS ('wykonaj szczegóły szukaj w innej tabeli relacji dla wierszy pasujących do warunków zawierających viewtable.oxid '), 1) ... itd.)
na widoku utworzonym jak
CREATE ... VIEW `viewtable` AS wybierz` table``OXID` AS `OXID`, ..., z (` table` join `relations`` t2s` on ((`t2s``OXMAPOBJECTID` =` table``OXMAPID`))) gdzie (`t2s``OXSHOPID` = 1)
Kiedy wymuszamy użycie tabeli podstawowej, użyj widoku, który nie został utworzony przy użyciu łączenia, lub po prostu dołącz do zapytania „kolejność według” , zestaw wyników jest poprawny. Po tym, jak się w to zagłębiliśmy , okazało się, że winowajcą jest ustawienie 'block_nested_loop',. jeśli tak jest, możemy uzyskać błędne zestawy wyników. Z MySQL 5.5 wszystko jest w porządku.
W OXID eShop jest jeszcze kilka miejsc, które używają podobnej struktury zapytań jak klasa oxDiscountList:
- oxActionList
- oxDeliveryList
- oxDeliverySetList
Działają jednak dobrze z MySQL 5.6 ze względu na wybór z innej struktury widoku tabeli lub dlatego, że używają zapytania z dołączonym „zamów przez” .
Podsumowując: tak długo, jak nie korzystamy ze zniżek na OXID eShop Enterprise Edition 5.2.x w MySQL 5.6.x, wszystko jest w porządku. Gdy stosowane są zniżki, ustawienie optymalizatora MySQL dla block_nested_loop powinno być ustawione na „wyłączone”, aby było po bezpiecznej stronie.
