ENCODE in aktueller MYSQL Version nicht mehr unterstützt


#1

Bei einem Umzug zu einem anderen Provider bekommen wir den Hinweis, das ENCODE in der vorlegenden MYSQL Version nicht unterstützt wird. Zurück auf eine ältere Version geht nicht, da Shared Hoster. Gibt es noch eine Möglchkeit ausser auf MariaDB umzuswitchen und wenn nicht gibt es ein besonderes Vorgehen oder etwas zu beachten beim Umzug auf MariaDB?


#2

Grundsätzlich arbeitet MariaDB einwandfrei. Es gibt aber in neuesten Versionen kleine Inkompatible Implementierungen. Welche MariaDB Version ist verfügbar?

Wobei MariaDB von OXID ebenso wenig supported wird, wie MySQL 8.X

Gruss
Marcel


#3

Derzeit läuft die Version 10.3.11. Ich habe auch folgendes probiert: ENCODE durch AES_ENCRYPT und DECODE zu AES_DECRYPT im Core zu ersetzen und dann in die MYSQL DB zu installieren. Das Setup läuft jetzt durch, aber dann läuft es zu anderen Fehler hinaus. Hier fehlt mir das Wissen weiteres zu probieren.


#4

10.3.11 wird nicht ohne weiteres funktionieren.

Da gibt es andere Probleme;-)
Gruss
Marcel


#5

Gibt es hier jemanden der bei WebGo einen 4.10.X laufen hat? Derzeitiger Stand ist, das die Installation auf MariaDB ohne Module und ohne Beispieldaten läuft.


#6

man kann diese mysql-Funktionen ersetzen aber dann sind damit alle alten Einträge in der oxconfig nicht mehr lesbar .
Habe gerade noch mal nachgesehen: auch in der aktuellen Version 6.X werden die Funktionen ENCODE / DECODE noch verwendet - d.h. der Shop läuft mit mysql 8.0.3 nicht mehr …
https://bugs.oxid-esales.com/view.php?id=6956


#7

Evt. müsste das Core-Team an dieser Stelle überlegen, ob das System so überhaupt noch einen Nutzen bringt, oder ob die Daten nicht auch in Klartext abgespeichert werden können. Vielleicht sogar als JSON.


#8

Ab mysql 8.0.13 geht noch mehr vor den Baum.
Gruss Marcel


#9

… ist anzunehmen - die Oxid-Entwickler müssen sich wohl mal mit mysql 8.X beschäftigen
Auch im bugtracker kann man z.Zt. noch nicht die MySQL-Version 8.X auswählen


#10

Weiter im Core rumzufummeln halte ich für unnützen Zeitvertreib. Wir wollen verkaufen und nicht ständig an Oxid rumbasteln.
Die MariaDB DB haben wir jetzt mit einem Backup gefüllt und greifen derzeit extern mit unserem Testshop darauf zu. Bisher keine Fehlermeldungen.


#11

das Ausweichen auf MariaDB ist sicher eine Möglichkeit, kann aber nur eine temporäre Lösung sein.


#12

Der Umzug ist geschafft. Unsere Seiten laufen auf dem neuen Server.


#13

Glückwunsch!
der Eintrag im bugtracker wurde übrigens geschlossen da 'Oxid die MySQL-Version 8.X nicht unterstützt’ - schon krass …
Alle Shopbetreiber laufen über kurz oder lang ins offene Messer da die Hoster - at the end of the day - ja auf MySQL 8.X updaten.
Dann hilft nur noch die Datenbank-Anbindung über MariaDB - die ja auch nicht von Oxid unterstützt wird …


#14

Die verwandte Argumentation bei der BUG Entry Schliessung gefällt mir überhaupt nicht. Ich denke mal, dass es absolut in der Verantwortung der OXID Entwickler liegt, solche CORE Komponenten entsprechend anzupassen und nicht einfach auf einen PullRequest seitens der Community zu hoffen.

Vielleicht kann ja @marco.steinhaeuser noch seinen Senf dazu abgeben :slight_smile:

Gruss
Marcel


#15

Ab Version 8 macht (meiner Meinung nach) Oracle mit MySQL genau das, weswegen MariaDB ursprünglich ins Leben gerufen worden ist. BIS Version 8 ist doch MariaDB in praktisch allen Belangen MySQL (CE) überlegen und voll kompatibel. Fakt ist auf jeden Fall, dass Oxid mit MariaDB tadellos und fehlerfrei läuft.

Ich rede hier nur von der CE Version von MySQL - dass irgendwelche Enterprise-Versionen besser sind, ist mir klar, aber da muss man aber auch keine Gefahr laufen, dass der Hoster einfach Updates einspielt. :sunglasses:


#16

Ich kann mir vorstellen, dass die nächste Version von Oxid auch stärker auf Symfony & Doctrine gepolt wird. Dann ist das ohnehin egal und kann “fix” durch Plugins ersetzt werden.


#17

Eine Änderung bzw. die Anwendung neuer Technologien ist durchaus sinnvoll, bedarf bei einem komplexen System sehr viel Arbeit.

Der Oxid Shop ist ein gewachsenes System und damit auch sehr komplex.
Die Oxid Entwicklung ist hinterher, neue Eindrücke und Möglichkeiten zu besprechen, entwickeln, testen und zu integrieren.

Das bedarf nun mal Zeit.

Jedes System hat seine Systemanforderungen (das System ist damit getestet und funktioniert) und diese sollte man erfüllen.
Abweichungen werden immer wieder auftreten, klar.

Mysql 8.0.11 wurde im April 2018 veröffentlicht und ist damit erstmal ein offizielles Release.
Die angesprochene Version 8.0.3 ist lediglich ein RC.
Die MySQL Version 5.7.x wird bis Oktokber 2020 unterstützt.
Erst im Oktober 2023 ist die Lebenszeit geplant vorbei.

Ich bin mir ziemlich sicher, dass die Oxid Entwicklung bereits das MySQL 8 Thema auf dem Schirm hat und Vorbereitung (seit V6 Symfony/Doctrine) für die neue Systemanforderung trifft.


#18

Ich hab das jetzt nochmal thematisiert.
Natürlich ist es richtig und wichtig, solche Informationen zu erhalten, dafür bin ich Euch sehr dankbar! Der Platz im Bugtracker ist auch gar nicht so falsch; wir haben die Vorgehensweise jetzt wie folgt besprochen:

  • Wenn jemand auf eine neuere Version der Systemumgebung stößt, wie z.B. PHP oder Datenbanken, und es kommt dort zu Fehlern wie hier in der Threaderöffnung beschrieben, kann gern ein Bug aufgemacht werden, damit wir Bescheid wissen.
  • Wir machen den Bug mit einem kleinen Dankeschön wieder zu und leiten direkt an das Produktmanagement weiter, damit die Unterstützung direkt in der Roadmap eingeplant und entsprechend gewichtet werden kann.

Ich hoffe, das passt so :wink:


#19

Ganz ehrlich Marco. Ich halte es für extrem wichtig, das hier eine schnelle Lösung geschaffen wird. Wir sind Anwender der Verkaufsplattform und wurden mit dem Umzug zu unserem neuen Provider völlig überrascht. Der Umzug auf einen anderen nicht supporteten Datenbanktyp zog andere Probleme nach sich, die wir ohne eine Agentur im Rücken nur müsam lösen können. Ich hoffe doch, das auch für bestehende ältere Installationen ein Workaround veröffentlicht wird, da für uns ein Wechsel auf Version 6 derzeit keinen Sinn macht.