mysqldb: UPDATE funktioniert mysteriöser Weise nicht

[samy-delux]

Ich habe auf einem meiner Server ein Python Skript, welches auf einen anderen Server mittels einer verschlüsselten MySQL Verbindung zugreift. So weit klappt auch alles.
Es wird mit den connect() Aufruf zu der Datenbank "dns" verbunden. Alle Queries dort gehen auch. Aber ich muss auch noch eine Query auf die Datenbank "test" laufen lassen.
Da kommen dann die Probleme ins Spiel:

Folgenden Code führe ich aus:

Code: Alles auswählen

command = "UPDATE `test`.`abuse` SET `active` = 1, `ip` = 'test' WHERE `defendant` = 'test@1';"
print mastercursor.execute ( command )

Ausgabe davon ist "5", was auch stimmt, denn es sollten 5 Rows betroffen sein. Doch an den Rows ändert sich absolut nichts:

Code: Alles auswählen

mysql> SELECT `active`, `ip` FROM `kilu`.`abuse` WHERE `defendant` = 'test@1';
+--------+----------------+
| active | ip             |
+--------+----------------+
|      0 | 84.168.187.174 | 
|      0 | 84.168.187.174 | 
|      0 | 84.168.187.174 | 
|      1 | 84.168.187.174 | 
|      0 | 84.168.187.174 | 
+--------+----------------+

Wenn ich die Query jedoch in PHPMyAdmin kopiere klappt alles wunderbar!
Vieleicht hat das Problem ja eine ganz Banale Lösung die mir nur nicht auffällt?
Schon mal danke für eure Hilfe!

so long,
Samy

[BlackJack]

`commit()` vergessen?

[samy-delux]

"commit()" ist doch dazu da um ganze Transaktionen in einem Zug auszuführen, oder? Brauche ich das hier??
Und wenn dann einfach ein executemany() machen und das "commit()" einfach hinten an das "UPDATE" dranhängen?

[BlackJack]

`commit()` ist dazu da die Transaktion (positiv) zu beenden. Wenn man das nicht macht, sind die Änderungen wirkungslos weil sie verworfen werden.

[samy-delux]

Danke für den Tipp. Liegt anscheinend daran dass mysqldb auto-commit ausschaltet. Scheint etwas gewöhnungsbedürftig, vor allem da ich nach einer kurze Google Suche gleich mehrere Leute gefunden habe die auch Lange nach einer Lösung suchten!

Aber hier gehts ja wie immer schnell

[BlackJack]

Das auto-commit aus ist, liegt an der DB API 2.0, da ist das so spezifiziert.

[Leonidas]

Ist ja auch sinnvoll. Stell dir vor, du machst aus versehen irgendeinen Schmarrn und Autocommit ist an. Dafür gibt es ein explizites Commit, so dass du im Falle von Fehlern (Exceptions) keine kaputten Daten in der Datenbank hast.

[jens]

Siehe auch [wiki]DB Transaktionen[/wiki]

[Y0Gi]

Ist ja auch sinnvoll. Stell dir vor, du machst aus versehen irgendeinen Schmarrn und Autocommit ist an. Dafür gibt es ein explizites Commit, so dass du im Falle von Fehlern (Exceptions) keine kaputten Daten in der Datenbank hast.

Warum sollte man Schmarrn machen? Wenn man Daten falsch aufbereitet in eine DB stecken will, hält einen das `commit()` auch nicht davon ab. Wird bei der Verarbeitung/Vorbereitung der Daten eine Exception geworfen, wird der Query selbst gar nicht erst ausgeführt.
Commits dienen nicht dazu, Fehler zu verhindern, sondern Zusammenfassen von Queries sowie Rollbacks (die man AFAIK auch nur bei mehreren Queries, die voneinander abhängen, einsetzt) zu erlauben.

Autocommit ist einfach etwas Komfort/weniger Arbeit, wenn man von vornherein weiß, dass man keine Transaktionen verwenden will (oder sich diese im Einzelfall irgendwie einfügen lassen).

[Leonidas]

Stell dir vor, du speicherst Daten in eine Datenbank. Du fängst also an reinzuschreiben (oder zu löschen), der Autocommit ist an, die Daten sind in einem inkonsistenten zustand, weil das alles nicht mit einem Query erledigt ist. Dann kommt etwas Code, der irgendwas macht und dann eine Exception wirft bevor die Konsistenz der Daten durch weitere Anweisunge wiederhergestellt werden konnte. Hereka, jetzt darfst du "per Hand" die Queries zückgängig machen (wobei per Hand auch meinen kann dass du Code brauchst, der die Daten richtet).

Das meinte ich.

[Y0Gi]

Ja, dafür gibt's Transaktionen. Wenn sich diese nicht explizit auch bei Autocommit nutzen lassen, sollte man natürlich Autocommit tunlichst deaktivieren.

Naja, die Sache ist wohl klar und wir meinen wohl dasselbe.