Grundsatzüberlegungen zur alten mysql-extension und der neuen mysqli-extension

[sysop]

Mich persönlich nevt es gewaltig.

Jetzt bricht die Zeit an, wo die mysql-Erweiterung langsam ausläuft und statt dessen mysqli verwendet werden sollte. Dazu eine Grundsätzliche Überlegung:

PHP kam viele Jahre mit der mysql-Erweiterung wunderbar zurecht. Fast alle Foren und Scripte die mit MYSQL gearbeitet haben basieren auf dieser Extension.
Bei mir schleicht sich der Verdacht ein, dass die neue Extension dazu da ist, das Dasein der Programmierer zu rechtfertigen, da angeblich ab Version 6 der Befehlssatz mysql nicht mehr unterstützt werden soll (ab Version 5.5 als DEPRECATED gekennzeichnet) und tausende gut funktionierender Scripte umgearbeitet werden müssen.

Dabei werden die Scripte durch mysqli nicht sicherer, schlechter Code bleibt weiterhin schlecht und sollte sich doch durch Zufall eine Sicherheitsverbesserung ergeben, wäre es sicher ein Leichtes, diese Verbesserung auch in die alte Extension einfliessen zu lassen.

Natürlich ist die OO SQL-Abfrage eine Neuerung, die zu begrüssen ist, allerdings stelle ich Vorteile von mysqli für prozeduale Datenbank Abfragen einfach mal in Frage.
Innovativ wäre gewesen, mysqli als OO Abfrage-Extension zusätzlich zu implementieren und die mysql-extension bei zu behalten.

Ausser, dass ich, wie gesagt, eigentlich tausende Scripte umarbeiten muss sehe ich keinen Vorteil. Im Gegenteil, manche Dinge scheinen mir wesentlich komplexer geworden zu sein und zu allem Überfluss hat man die Syntax derart geändert, dass ein simples Suchen/Ersetzen in den Scripten nicht funktionieren wird.

Facit, ich habe mir einen Wrapper geschrieben, der mir die alten Befehle in die neuen übersetzt und Wrapper sind nunmal (wie jeder selbst weiss) nicht das Gelbe vom Ei. Ich sehe aber nicht ein, dass ich hunderte Scripte durchackere. Scripte die seit Jahren ihren Dienst tun und die durch ständige Anpassungen nahezu fehlerfrei geworden sind laufen nun Gefahr, mit neuen Fehlerquellen infiziert zu werden.

Ich sehe es grundsätzlich als ein schweres Vergehen an, wenn in Programmiersprachen Befehle ausgetauscht werden, also bestehende durch neue ersetzt werden. Als würde diese Scriptsprache gerade erst am Anfang stehen und es käme auf die paar bestehenden Scripte nicht an.
Ich denke, dass, würden cp, ls, awk, grep, chmod un alle amnderen auf einmal vollkommen anders reagieren oder abgeschafft, dass das Ende einer Betriebssystem-Ähra bedeuten könnte.

Meine persönliche Überlegung geht sogar dahin, zukünftig auf PHP vollkommen zu verzichten, da ich nicht gewillt bin, "Leichencode" zu produzieren, sprich Code, der nach ein paar Jahren seinen Dienst nicht mehr tut, weil es die Befehle nicht mehr gibt. Die Kunstgriffe, die man bei PHP ständig veranstalten muss, kotzen mich persönlich regelrecht an.
Eine Sprache die seit 1995 besteht kann es sich meiner Meinung nach nicht leisten, nicht kompatibel zu bleiben, schon garnicht, wenn sie ladbare Module anbietet, die auf nahezu allen gängigen Servern laufen.

Just my 5 Cent......

PS
Wer alle mysql Befehlssätze auf einem Linux deaktivieren möchte macht folgendes:

 cd /etc/php5/conf.d[COLOR=#000000][COLOR=#0000BB][/COLOR][COLOR=#007700][/COLOR][/COLOR]

ändere die Datei mysql.ini und setze ein rem vor extension=mysql.so

 

[bdt600]

Vom Prinzip her kann ich dir nur zustimmen. Allerdings sehe ich einen Umbau auf MySQLi nicht ganz so dramatisch. Zu 99% reicht ein Substitute von mysql_ nach mysqli_ und das war es dann schon. Aber kein Zweifel, das hätten die PHP-Entwickler geschickter lösen können. Einfach die Funktionsnamen belassen und im Hintergrund können sie ja MySQLi benutzen. Wäre für diejenigen, die PHP benutzen einfacher gewesen.

 

[ge_fabian]

mhh also ich kann dir auch zustimmen, aber ich denke: wieso nicht mal was neues?

man muss ja nicht auf MySQLi setzen, ich persönlich werde wohl auf PDO gehen!

Eigentlich wollten die PHP Entwickler die mysql Extensions mit Version 5.2 entfernen, man hat es dann aber doch noch gelassen.

Ich frage mich auch, was alle dann machen: Sehr sehr sehr viele Seiten laufen mit den mysql Befehlen.

Und im Endeffekt kann man sich sowieso nicht gegen währen, wieso auch?

Damit müssen / oder auch nicht / wir leben.

Aber einen Ausweg gibt es wohl doch noch: seine Server nicht updaten ;)

Aber die ganzen Webhoster werden dies wohl tuen, von daher, dumm..

Man kann es aus vielerlei Hinsicht sehen, ich bin ehrlichgesagt dafür!

 

[sysop]

....
Aber einen Ausweg gibt es wohl doch noch: seine Server nicht updaten ;)

Das wird wohl einer der schlimmsten Auswege werden. Das bedeutet veraltete Systeme.
Viele Firmen (fast alle meine Kunden) haben sich ihre Scripte exklusiv anfertigen lassen und müssten eine Umarbeitung der alten Script extra bezahlen. Erste Kunden fragen schon was dann sein wird, daher habe ich mir eben einen wrapper geschrieben. Allerdings ist das ein Krüppelweg.

....
Aber die ganzen Webhoster werden dies wohl tuen, von daher, dumm..
Man kann es aus vielerlei Hinsicht sehen, ich bin ehrlichgesagt dafür!

Du bist dafür, dass eine Scriptsprache in sich inkonsistent wird, weill die Entwickler meinen, einen ganzen Befehlssatz abschaffen zu müssen, was angesichts des zu ladenden Modules vollkommen Sinnfrei ist? Der neue Befehlssatz ist syntaktisch auch noch anders zu verwenden und ist nicht zu 100% kompatibel.

Stell dir vor, du schreibst einige hundert Scripte basierend auf PDO und dann wird das Modul plötzlich abgeschafft. Der Krach mit deinen Kunden ist vorprogrammiert.
Zum besseren Verständnis: Ich habe hier 7 Server, die alle mit 99% selbst erstellten (verschiedensten) Scripten laufen und deren Funktion zu 100% sichergestellt sein muss.

 

[philip0908]

arbeite objektorientiert und schreib dir eine klasse, die die datenbankfunktionalität regelt. fertig.
musst du halt einmal deine db-klasse ändern und kannst die dann weiter benutzen. dauert maximal 1-2 stunden bist alles wieder so läuft, wie vorher.
du solltest so oder so nicht direkt im script mit datenbankbefehlen hantieren, erschwert bei großen projekten nur das debuggen.
frage mich, wie du die abfragen implementiert hast, wenn du sie in 100en scripten ändern musst.

 

[sysop]

Danke für den Tipp, ich mache das aber schon seit 20 Jahren und bin nicht ganz unbedarft.
Und es geht nicht um 1 Script, sondern um gut 2500.
Und einen Wrapper habe ich schon, es bleibt also alles beim Alten und es wird nichts geändert. Muss ihn halt in die Scripte einbinden.

 

[bdt600]

Man kann daran aber auch etwas Positives finden. Wenn die MySQL-Extension entfällt, werden sich bestimmt einige bei mir melden und ihr Leid klagen, dass ihre Seite nicht mehr funktioniert. So kann man auch Geld verdienen

 

[derMartin71]

Moin Moin,

die mysqli Extension existiert seit PHP Version 4.1 ... also ca. 2004/2005 ... Wer in dieser Zeit die Vorzüge von mysqli vs. mysql (Prepared Statements z.B.) nicht kennen und schätzen gelernt hat, dem ist meiner Meinung nach nicht zu helfen. Wenn man jetzt natürlich anfängt, die Codebase von der alten mysql Extension zu befreien, sollte man natürlich direkt auf PDO gehen, wenn man schon bei PHP bleibt.

-just my 2ct.

Gruß
/martin

 

[sysop]

Über Möglichkeiten und Vorteile die in mysqli stecken mag und kann ich nicht streiten, die sehe ich selbst.
Prepared Statements und Stored Procedures in allen Eheren, wenn Bedarf besteht ok.

Mein Unmut bezieht sich darauf, dass eine Scriptsprache die über Extensions Befehlssätze zur Verfügung stellt, diese (meiner Meinung nach willkürlich) eleminiert.
Pflegeleicht ist die mysql-Extension alle mal und mysqli mit allen Vor/Nachteilen in eine eigene Extension zu packen wäre keine wirkliche Herausforderung gewesen. Eine 42k Extension mit zu pflegen kann das Problem wohl nicht sein.
Sich selbst auf mysqli einzuschiessen ist nicht das Problem. Viel mehr die Tatsache, dass gut funktionierende Scripte in absehbarer Zeit den Dienst versagen werden (übrigens etwas, was ich bisher in diesem Ausmass in keiner Scriptsprache gesehen habe).

Mein Unmut bezieht sich auch darauf, dass nahezu jeder Programmierer (die übrigens selbst auch in einem hohen Mass mysql eingesetzt haben) diesen Prozess begrüsst, weil damit die eigene Tätigkeit gerechtfertigt wird. Haben die alle nichts zu tun oder geht es wieder mal nur ums Moos?
Denen, die den aufwendigen Weg des Umarbeitens, dem einfachen Weg der Erweiterung vorzuziehen, denen kann ich wiederum nicht helfen. Da wird nach Transparenz und Flexibilität geradezu gebrüllt und dann sowas.

 

[derMartin71]

Ich kann es auch nur begrüßen, dass bei neuen PHP Versionen (oder jeder anderen Sprache) die als "deprecated" markierten Funktionen irgendwann mal entfernt werden. Denn für jede dieser Funktionen braucht man wieder Maintainer, die das pflegen müssen. Zum Beispiel bei der Umstellung auf UTF-8 oder 64bit. Des Weiteren werden ja die Legacy Versionen (zB. 5.3.x) weiter gepflegt und mit Sicherheitspatches versorgt. Wer also nicht die neuesten Sprachfeatures benötigt, muss ja auch kein Upgrade machen.

 

[sysop]

Drüber zu diskutieren, das war ja der Sinn meines Themas.

Die Umsetzung von deprecated ist mir schlicht ein persönlicher Graus und schon lange ein Dorn im Auge. Andere Sprachen lösen das elegenter, indem die Module weitestgehend kompatibel gehalten werden oder Layer-Module angeboten werden (Perl).
Schlechte Eigenschaften von Scriptsprachen lassen sich anders umgehen als sie zu killen, z.B. sie einfach nicht zu nutzen und als Modul weiter anzubieten. Man hat sich wohl nur daran gewöhnt, dass man von allen Seiten vor vollendete Tatsachen gestellt wird. Zumal die mysql-extension ja nicht schlecht ist sondern mysqli nur umfangreichere Funktionalität bietet.

Fehler in Scripten zu provozieren bedeutet für mich persönlich eine Scriptsprache generell in Frage zu stellen, weil man nie weiss, was als nächstes kommt.
Diesmal bin ich betroffen, weil ich mich mit dem Zeug rumärgern kann. Der Zeitaufwand ist nicht so gering und Ich bin eigentlich kein Freund davon, sich Arbeit künstlich zu schaffen, zumal diese Arbeit schon getan ist, die Scripte sind bereits geschrieben und laufen.

Maintainer, ja ist schon klar. Ich weigere mich zu akzeptieren, dass die mysql-extension so aufwendig zu warten ist. Mein mysqli-layer hat knapp 2 Stunden Arbeit gemacht und schon kann ich weitestgehend mit den alten Befehlen auch ohne mysql extension arbeiten, sowas als Alternative in einem Modul anzubieten kann das Problem nicht sein und ich könnte mir das Bearbeiten der Scripte sparen, wo ich den Layer erst noch einbinden muss. Zumal nach meiner Auffassung ein derartiger Layer nahezu wartungsfrei wäre (vorausgesetzt, man ändert nicht wieder etwas an der Syntax).

Die mysqli Befehle dann auch noch so inkompatibel zu gestalten (z.B. ein mysqli_filed_name, mysqli_field_flags oder mysqli_field_len gibt es nicht, aus mysql_select_db($dbname, $link) wird ein mysqli_select_db($link, $dbname) also Funktionsparameter ungedreht) dass die Umarbeitung nicht mit sed/awk zu bewerkstelligen ist und zu einem Frickelwerk wird, nun gut. Wäre dass denn nun so schwer gewesen.

Nochmal, ich habe ja bereits eine Lösung für mich gefunden und ich werde es wie alle Kunden fressen müssen. Glücklich muss ich aber nicht sein. Ich finde nicht wirklich die Umstellung auf mysqli schlimm, vielmehr deren Umsetzung.

 

[derMartin71]

Die mysqli Befehle dann auch noch so inkompatibel zu gestalten (z.B. ein mysqli_filed_name, mysqli_field_flags oder mysqli_field_len gibt es nicht, aus mysql_select_db($dbname, $link) wird ein mysqli_select_db($link, $dbname) also Funktionsparameter ungedreht) dass die Umarbeitung nicht mit sed/awk zu bewerkstelligen ist und zu einem Frickelwerk wird, nun gut. Wäre dass denn nun so schwer gewesen.

Naja, im Prinzip ist PHP ja ein Frickelwerk, oder war es zumindest mal ;)

Das zieht sich bei PHP ja leider durch einen ganzen Haufen von Funktionen ... siehe Stringfunktionen ... mal $needle, $haystack ... und bei der nächsten wieder ... $haystack, $needle. Trotzdem denke ich, dass es absolut Sinn macht, bei einem Major Versionssprung einfach mal einen Cut zu machen. Siehe auch Python 2.x -> 3.x und Ruby. Meiner Meinung nach, hat gerade PHP dies nötig. Erst war es eine prozedurale Sprache, dann haben sie angefangen den OO Kram mehr schlecht als recht dran zu basteln, wo jedes Objekt erstmal nichts weiter war als ein assoziatives Array.