Seite 2 von 2
Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Dienstag 18. Februar 2014, 15:57
von /me
mephisto-online hat geschrieben:Kann man denn mehrere commits zurückrollen, d.h. gibt es sowas wie ne history ?
Ein COMMIT kann man gar nicht zurückrollen.
Wenn du vor deinem COMMIT mehrere offene Aktionen (INSERT, UPDATE, DELETE) hast und beim COMMIT auch nur eine davon fehlschlägt, dann wird keine der Aktionen ausgeführt. Genau das ist ja der Sinn einer Transaktion.
Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Dienstag 18. Februar 2014, 16:04
von snafu
mephisto-online hat geschrieben:Kann man denn mehrere commits zurückrollen, d.h. gibt es sowas wie ne history ?
Eine Datenbank ist kein Versionsverwaltungssystem. Das Zurückrollen eines Commits ist daher nicht vorgesehen.
Eine Historie über die Aktualisierungen der Einträge kann man aber führen. Das Stichwort hierzu lautet
Temporale Datenhaltung. Die Änderungen können damit samt Zeitstempel direkt in der Datenbank festgehalten werden. Falls du denn das überhaupt meintest...
Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Dienstag 18. Februar 2014, 16:41
von bfm
mephisto-online hat geschrieben:@bfm
Kann man denn mehrere commits zurückrollen, d.h. gibt es sowas wie ne history ?
Ein commit heißt für die DB, schreibe jetzt die Daten "hart" in die Tabellen. Bis zu einem commit können (fast) alle Änderungen durch ein rollback zurückgedreht werden. Erst mit dem commit sind die Änderungen in der Datenbank auch für andere User sichtbar.
Beginne Transaktion
=> ändere Tabelle A
=> ändere Tabelle B
=> ändere Tabelle C
Beende Transaktion
==> wenn kein Fehler aufgetreten ist ==> commit ==> schreibe alle Daten hart auf die Platte
==> bei einem Fehler oder vielleicht, weil der User die Aktion abbrechen kann (Simulation der Datenänderung) ==> rollback ==> dreh alles wieder zurück wie vor Beginn Transaktion
Eine history musst wahrscheinlich selber programmieren. Da kommt es dann darauf an, was du als Ergebnis willst.
Es kann ausreichend sein, alle Änderungen einfach in einer (Logging-)Tabelle zu protokollieren: Tabelle x, Feld a, Wert alt = 1, Wert neu = 2, Datum, Uhrzeit, User
oder
in der Tabelle x hat jeder Datensatz noch ein zusätzliches Feld für "gültig ab". Falls Lücken in der Historie erlaubt sein sollen noch zusätzlich "gültig bis"
Heutige Standardsoftware bietet beides. Erstens muss nach dem BDSG feststellbar sein, wer wann welche Daten eingibt, ändert oder löscht und zweitens will man mit der historischen Datenhaltung eine Art Archivierung erreichen.
mfg
Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Dienstag 18. Februar 2014, 20:07
von mephisto-online
noisefloor hat geschrieben:eine Transaktion ist eine oder eine Gruppe von Datenbankoperation (Schreiben, Ändern, Löschen etc.), die explizit ausgeführt werden müssen (Befehl "commit") und bei Bedarf auch rückgängig gemacht werden können (Befehl "rollback").
Aber andere schreiben hier doch, dass das nicht geht (commit ist endgültig, so, wie bei einer ISAM-DB). Oder ist gemeint, dass mit rollback lediglich Transaktionen rückgangig gemacht werden können ? Was passiert denn genau bei einer Transaktion, ist das was virtuelles, was erst mit commit physikalisch wird ? Gibt es das Ergebnis von Transaktionen erst mal nur in einer Session und werden erst beim Schliessen der Session explizit commited (oder auch nicht) ?
Transaktionen sind mir offensichtlich immer noch nicht ganz klar !

Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Dienstag 18. Februar 2014, 20:26
von noisefloor
Hallo,
ok, das ist missverständlich ausgedrückt. Eine Transaktion kann mit "commit" oder "rollback" abgeschlossen werden. Ersteres führt die Transaktionen tatsächlich aus und schreibt diese endgültig in die Datenbank, letzteres verwirft alle Befehl innerhalb der Transaktion und die Datenbank ist auf dem Stand wie vor Beginn der Transaktion.
Der deutsche Wikipedia-Artikel beschreibt das aber auch ganz gut:
http://de.wikipedia.org/wiki/SQL#Transa ... d_Rollback
Gruß, noisefloor
Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Dienstag 18. Februar 2014, 20:43
von mephisto-online
Ok ! Danke Euch allen ! Werde da wohl doch erst mal noch einiges lesen müssen...
Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Dienstag 18. Februar 2014, 21:06
von noisefloor
Hallo,
wichtig für den Projekt ist noch:
Die ISAM-Engine kennt keine Transaktionen, SQLite schon. Wenn du also z.B. einen "INSERT ..." Befehl ausführst, schreibt MariaDB / MySQL das sofort, SQLite erwartet aber noch ein "commit", sonst passiert nix (sofern du nicht SQLite im Autocommit-Modus betreibst).
Gruß, noisefloor
Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Dienstag 18. Februar 2014, 21:44
von mephisto-online
@noisefloor
noisefloor hat geschrieben:Die ISAM-Engine kennt keine Transaktionen, SQLite schon.
Habe ich schon gelernt, danke !
noisefloor hat geschrieben:Wenn du also z.B. einen "INSERT ..." Befehl ausführst, schreibt MariaDB / MySQL das sofort...
Aber doch nur dann, wenn Tabellen mit der ISAM-Engine generiert wurden. Bei InnoDB-Tabellen ist das doch nicht so, oder ?
Re: Bidirektionaler Abgleich SQLite <-> MariaDB ?
Verfasst: Mittwoch 19. Februar 2014, 08:48
von noisefloor
Hallo,
genau. Bei InnoDB muss du auch explizit commiten.
Gruß, noisefloor