Lukas: Übersetzungsfrage mysql_* zu PDO

Hallo,

ich möchte folgenden Block, der derzeit als mysql_ - Funktion notiert ist, testhalber als PDO notieren:

Mysql:

  
$result=mysql_query($query);  
if ($result==FALSE)  
     {  
my_mysql_error($query); // notiert die fehlerhafte Query in der db und gibt neutrale Meldung aus, bevor das Script an dieser Stelle gestoppt wird.  
     }  
while ($row=mysql_fetch_row($result)) { ...  

PDO

  
$result = $db->query($query);  
if ($result==FALSE)  
     {  
my_mysql_error($query); // notiert die fehlerhafte Query in der db und gibt neutrale Meldung aus, bevor das Script an dieser Stelle gestoppt wird.  
     }  
while ($row = $result->fetch()) {...  

Ist das so korrekt gedacht?

Scheint mir irgendwie nicht ganz zufriedenstellend. PDO hat doch ansich eine eigene Fehlerbehandlung, oder? Aber wie bekomme ich aus der z.b. die fehlerhafte Query in meine Fehlertabelle und wie erhalte ich darüber eine Mail?

Ich arbeite mit PDO zwar dann objektorientoiert und halbwegs db-übergreifend, aber es ist ziemlich viel Arbeit, das umzustricken und es gibt wenig sichtbare Vorteile für mich.

Lukas

  1. Tach!

    PDO
    $result = $db->query($query);
    if ($result==FALSE)

    Ist es wahr, dass $result false ist? if (!$result) reicht aus.

    {
    my_mysql_error($query); // notiert die fehlerhafte Query in der db und gibt neutrale Meldung aus, bevor das Script an dieser Stelle gestoppt wird.
         }
    Ist das so korrekt gedacht?
    Scheint mir irgendwie nicht ganz zufriedenstellend. PDO hat doch ansich eine eigene Fehlerbehandlung, oder?

    Ja, und die solltest du auch verwenden. Da gibt es aber drei Arbeitsweisen, über die du dich erstmal informieren und für eine entscheiden solltest. Wenn deine Funktion my_mysql_error() intern mysql_error() oder andere mysql_*-Funktionen aufruft, dann wüsste ich nicht, ob dabei das gewünschte Ergebnis rauskommt. Diese Funktionen wollen ja eine Verbindungskennung und wenn sie keine bekommen, holen sie sich eine. Ob sie die von PDO verwaltete bekommen, wäre dann die Frage. Jedenfalls ist ein Mischmasch der Systeme nicht der richtige Weg.

    Ich arbeite mit PDO zwar dann objektorientoiert und halbwegs db-übergreifend, aber es ist ziemlich viel Arbeit, das umzustricken und es gibt wenig sichtbare Vorteile für mich.

    DB-übergreifend sollte man als Kriterium nicht überbewerten. Das ist sicher sinnvoll, wnen man Projekte erstellt, bei denen der Verwender die Entschiedung über das DBMS haben soll. Für Programmierer mit selbst verwaltetem Server ist das nachrangig. Warum sollte man zu einem anderen System wechseln, wenn man da auch nur haargenau denselben Funktionsumfang nutzt? Aus administrativer Sicht mag es da Gründe geben. Möchte man als Programmierer aber DBMS-spezifische Vorteile nutzen, muss man sowieso die betreffenden Teile umschreiben, da hilft eine DB-übergreifende Abstraktion nicht übermäßig viel. Sie könnte sogar das Vorhaben verhindern.

    dedlfix.

    1. Hi dedlfix,

      Ja, und die solltest du auch verwenden.

      Werde ich.

      Ob sie die von PDO verwaltete bekommen, wäre dann die Frage. Jedenfalls ist ein Mischmasch der Systeme nicht der richtige Weg.

      Kommt Zeit, kommt "richtiger Weg", derzeit ist es Mischmasch. Was daran liegt, daß damit beide Versionen (PDO und mysql_*) zurecht kommen. Ich muß erst mal alle Skripte umstricken, danach korrigiere ich die Fehlerbehandlung.

      DB-übergreifend sollte man als Kriterium nicht überbewerten. Das ist sicher sinnvoll, wnen man Projekte erstellt, bei denen der Verwender die Entschiedung über das DBMS haben soll. Für Programmierer mit selbst verwaltetem Server ist das nachrangig. Warum sollte man zu einem anderen System wechseln, wenn man da auch nur haargenau denselben Funktionsumfang nutzt? Aus administrativer Sicht mag es da Gründe geben. Möchte man als Programmierer aber DBMS-spezifische Vorteile nutzen, muss man sowieso die betreffenden Teile umschreiben, da hilft eine DB-übergreifende Abstraktion nicht übermäßig viel. Sie könnte sogar das Vorhaben verhindern.

      Dann verstehe ich insgesamt nicht so recht, daß ich umsteige. Aber vielleicht kommen die Vorteile bei Prepared Statements zum tragen.

      Und noch eine Frage: Gibts irgendein gescheites Gegenstück zu mysql_num_rows? Ich lese immer wieder, daß $result->rowCount() nicht sauber funktionieren soll?

      Lukas

      1. Tach!

        Dann verstehe ich insgesamt nicht so recht, daß ich umsteige. Aber vielleicht kommen die Vorteile bei Prepared Statements zum tragen.

        Die herkömmliche mysql-Extension wird in Zukunft wegfallen (dauert aber sicher noch ein paaar Jährchen). Prepared Statements sind auf alle Fälle von Vorteil, weil du dir damit das fehlerträchtige Zusammenstückeln von SQL-Code und Werten zu einem Statement sparen kannst.

        Und noch eine Frage: Gibts irgendein gescheites Gegenstück zu mysql_num_rows? Ich lese immer wieder, daß $result->rowCount() nicht sauber funktionieren soll?

        Wenn du auf der englischen Version des PHP-Handbuchs schaust, ist immer eine Alternative zur herkömmlichen Funktion genannt. In dem Fall ist das rowCount(). Das kann nicht in allen Systemen richtig arbeiten, was aber an der jeweiligen DBMS-API liegt. Das Problem gibt es auch nur bei SELECT. Die Funktion kann die Anzahl erst dann kennen, wenn alle Datensätze vom Server abgeholt worden sind und somit gezählt werden können. Die MySQL-API macht das unbemerkt im Hintergrund beim Query mit. Das Fetchen holt dann nur von diesem Zwischenspeicher. Jedenfalls ist durch das "heimliche" Abholen die Anzahl bekannt und kann sofort geliefert werden, bevor du das Fetchen anfängst. Da andere Systeme das Fetchen vom Server auch erst beim Aufrufen der Fetch-Funktionen durchführen, kann rowCount() die Anzahl nicht gleich sofort liefern, sondern erst nach Abschluss des Fetch-Vorgangs. Deshalb kann man sich auf das Ergebnis der Funktion rowCount() nicht systemübergreifend verlassen - jedenfalls nicht vor dem Fetch-Abschluss.

        Das ist jedenfalls meine Erklärung, warum es technisch gesehen teilweise nicht gehen kann. Leider steht im Handbuch nicht, dass die Funktion nach dem Fetchen garantiert die richtige Zahl liefert. Vielleicht ist da ja wirklich kein Zählmechanismus eingebaut und PDO nimmt da nur, was die APIs liefern. Als Alternative ist jedenfalls immer ein SELECT COUNT(*) ... möglich.

        dedlfix.