Nabend.
Ich frage mich gerade, wann OXID offiziell mal MariaDB unterstützen will. Selbige ist mittlerweile beispielsweise Standarddatenbank bei Debian,CentOS und Fedora.
Grundsätzlich läuft es ja, allerdings gibt es Probleme ab bei MariaDB ab Version 10.2.7 , Bugfixing wird logischerweise mit not supported abgelehnt, allerdings setzt auch MySQL ab Version 8.0.13 diesen sinnvollen Teil ein. Ja ich weiss, 5.5 und 5.7 sind offiziell supported aber 5.5 ist auch dieses Jahr EndOfLife.
Über kurz oder lang wird es also zu einem Fix kommen müssen.
Denkt bei OXID in diesem Bezug eigentlich mal jemand langfristig?
Aus meiner Sicht bietet sich gerade mit MariaDB und zusätzlichen Programmen, eine Möglichkeit zur Performance Steigerung der Oxid Shops, die sogar Varnish überflüssig machen können.
Latest Release ist nicht zwingend, aber auf neue Software nach Jahren zu reagieren auch falsch!
Schon, aber nicht in Bezug auf MariaDB. Meines Wissens hatte Monty seinerzeit MySQL verlassen, um MariaDB zu gründen. Und meines Wissens ist es auch so, dass es kaum bzw. keine Unterschiede gibt - Wunder oh Wunder ^^
Wir können als Hersteller einer Applikation nicht alles supporten, was grad bei drei nicht auf dem Baum ist und haben uns deshalb entschieden, feste Rahmen zu schaffen, innerhalb derer OXID halt läuft. Das sind dann die sog. Systemvoraussetzungen (ja, geht bald in die Doku )
Um nochmal aasiger zu werden: Was meinst Du mit “Standarddatenbank” bei Debian…?
Meines Wissens installiert man ein LAMP stack via $ apt install apache mysql-server etc. oder eben anders. Insofern sehe ich da keine Standard-Datenbank. Oder was meinst Du?
Die Thematik wird übrigens nicht leichter, wenn man über die kommerziellen Alternativen wie M$ SQL oder ORACLE nachdenkt… Wobei das schon hübsch wäre ^^
Ich möchte ungern mit Dir hier eine Diskussion über die Datenbanken, Apache Versionen oder sonstwas lostreten.
Seit Debian 9 ist, wenn immer eine Abhängigkeit von MySQL existiert, eine automatische Installation von MariaDB vorgesehen.
Zum Thema support: MySQL 5.5 ist am 03.Dez 2018 8 Jahre alt und EndOfLife. Ja, MySQL 5.7 wird noch etwas länger supported, aber mit Version 8 kommt ein gleiches Kompatibilitätsproblem auf OXID zu.
Wenn man nun mal Eure Release History so anschaut, supported ihr auch nur maximal 4 Jahre, Beispiel OXID 4.9.
Und deswegen war die ursprüngliche Frage, warum Ihr z.B. 8 Jahre alte Datenbankversionen supported, aber keine die relativ aktuell sind. Wobei MariaDB 10.2 auch schon 3 Jahre alt ist.
Aber gut, man kann es ja fixen und die Vorteile der aktuellen Datenbanken weiternutzen.
Und noch ein Nachtrag, ab 03.12.2018 ist PHP 7.0 (auch php 5.6) EOL und erhält offiziell KEINE Securitypatches mehr. Der funktionale Support ist ja schon seit 9 Monaten beendet.
Vielleicht konzentriert Ihr Euch erstmal darauf…
Gruss
Marcel
Ich denke mal, dass das dem Mainstream (der breiten Masse) zugeschrieben werden muss.
Ca 99,5% der Hoster laufen mit MySQL 5.5 oder 5.6 (Profihost hat seit Februar 5.6), vor 1-2 Jahren fingen einige parallel MariaDB anzubieten. Debian 9 bekommt man auch bei kaum einem Hoster, bestenfalls für eigenen virtuellen Server.
Gerade in dem Web Bereich setzen die Leute auf “alt und bewährt” (alle Bugs langsam bekannt und gefixt) und nicht auf “gestern released”. Einige Hoster haben erst kürzlich PHP 5.2 abgeschaltet.
Aus der wirtschaftlichen Sicht macht es auch keinen Sinn, wöchentlich Server und Application Updates einzuspielen, nur damit die Versionsnummer aktueller ist.
Marat,
dass es nicht um den ‘normalen’ CE User geht ist klar.
Und dass die Hoster Probleme haben mal eben für Tausende Seiten eine Programmversion abzuschalten,ist auch klar.
Ich bin ja auch schon ruhig.
Gruss
Marcel
Oxid will ja immer so bemüht “international” sein… Hoster die nicht in D-Land sind bieten da schon laaange MariaDB an. Passt dann irgendwie nicht dazu sich nach den Vorlieben /dem Verhalten ausschließlich von Hoster´n aus D-Land zu richten…
Bei Oxid ist Marketing am wichtigsten, schwere Fehler und Unzulänglichkeiten welche seit Version PE 3.xx… irgendwas bekannt sind wurden bis heute nicht gefixt oder verbessert…
@mws_1941 - Marcel, versteh mich da bitte nicht falsch: Ich sage, dass wir die Tests unter MySQL laufen lassen und deshalb in die Systemvoraussetzungen schreiben können: “Getestet mit MySQL Version X und Version Y”. Das ist das, wovon wir definitiv behaupten können, dass es läuft. Wir sagen nicht, dass der Shop unter MariaDB nicht läuft. Aber aktuell wird MySQL getestet unterstützt.
Ich persönlich sage, dass MariaDB nicht zwangsläufig die Weiterentwicklung von MySQL darstellt - es ist halt ein Fork, der ggf. ab einer bestimmten Entwicklungsstelle völlig anders aussehen kann. (Dieses Szenario mag künftig komplett anders sein, wenn die Testumgebung auf Docker-Umgebungen umgestellt wird, die man einfach mal so fix hin- und herschalten kann; momentan ist das aber noch nicht gegeben - wir arbeiten dran.
@vanilla_thunder hat da übrigens einen absolut richtigen Aspekt eingeworfen. Wir sind da halt ständig mit den Hosting-Providern in Kontakt, informieren über Änderungen von Systemvoraussetzungen, reden miteinander, führen Abfragen durch etc., damit wir gemeinsam hochziehen können.
@Mj.Kater, es ist ja schön, Dich hier wiederzusehen und inzwischen hat sich der Kratzbaum etwas verändert. Wenn Du da etwas Konkreteres hättest: Schick mir das doch bitte per PN zu, und ich bemühe mich, dass ich da etwas erreichen kann. Diese verallgemeinerten Aussagen sind immer ein bisschen anstrengend zu bearbeiten. Oder reich halt einen Pull-Request auf GitHub ein
es geht in erster Linie darum das der Oxid-Shop seit der Version 3.x.x in erhaltenen Bestellungen die Artikel Preise abändert wenn sich diese geändert haben. Es gibt zwar “Krücken”-Patches, welche aber dann gleich gar keine Änderungen an den Bestellungen mehr zulassen. Änderungen an Bestellungen und dazu zählen auch das eintragen der Tracking Nummer und Änderung des Status auf Verschickt, oder das Hinzufügen von Artikeln bzw. deren löschen, dürfen keine Preise innerhalb der Bestellungen verändern.
Dieser Super-Bug ist seit Jahren, OHNE Konsequenz, in der Fehlerliste enthalten. Wir sind jetzt bei 6.x.x und es gibt diesen Fehler immer noch.
Ein Teil der Schuld liegt mit Sicherheit bei MariaDB. Wie kann man von Version 10.2.6 auf 10.2.7 eine derartige Veränderung am Verhalten der Datenbank implementieren? Das geht einfach nicht.
Aber wie kann man auf der anderen Seite auf die Idee kommen, denn Default-Wert aus dem Information-Schema auszulesen, um ihn dann selbst als Default-Wert vorzubestücken?
Natürlich schreibt ihr bei Oxid, dass MariaDB nicht unterstützt wird. Aber hört doch auch mal auf die Wünsche der Community. Die Merge-Request der Community mit Bugfixes nehmt ihr doch auch dankend an, oder?
Scheinbar hat euch einer eurer Partner sogar kostenlose Server für automatisierte Tests mit MariaDB angeboten. Nehmt das Angebot doch an.
Es wurde entdeckt, dass mit der neuen Funktion in den default-Wert auch functions oder expressions zu akzeptieren es nicht eindeutig erkennbar ist, wie die Tabelle angelegt werden soll. Und dabei ist man wohl noch darüber gestolpert, dass der SQL Standard literals in single quotes vorsieht so wie es auch andere Datenbanken zurück geben. Beispiele dafür im Jira-Bugreport von MariaDB.
In der Gesamtheit natürlich keine gute Sache für Oxid und MariaDB in Kombination.
Da wir auch selbst gerne MariaDB für Oxid-Projekte einsetzen, haben wir - wie @svenk66 es schon geschrieben hatte - Oxid angeboten eine Testinfrastruktur bereitzustellen um eine offizielle Unterstützung von MariaDB zu unterstützen bzw. zu fördern. Leider wurde dies aus verständlichen Gründen nicht angenommen.
)