Transaktion wird bei Fehlermeldung automatisch zurückgesetzt

Dann mußt Du der Applikation die Aufgabe zumuten, für Datenkonsistenz zu sorgen. PG hat den Ansatz, sich diese für eine Datenbank elementare Aufgabe nicht aus der Hand nehmen zu lassen, im Gegenteil, es nimmt diese Aufgabe sehr ernst. Sehe es positiv.

Andreas

Symbiont: so sehe ich das auch, müssen wir halt akzeptieren :wink:

Vielen Dank für die Hilfe!

Datenkonsistenz und Transaktions-Handling sind zwar nicht unabhaengig - aber zwei paar Schuhe.

Ein fehlgeschlagenes DML-Kommando ist KEINE Gefahr für die Konsistenz. Eine TX hebelt Constraint-Checks nicht aus!

Eine TX legt ausschließlich fest, welche (erfolgreich durchgeführten) Änderungen atomar geschrieben werden sollen. Und wenn beim COMMIT von ausfuehren 50 INSERTS oder UPDATES (incl Fehlerbehandlung) am Ende nur noch 3 effektive Änderungen über bleiben, dann entspricht die TX eben “3 Änderungen schreiben” …

Die COMMIT-Oparation selbst darf dann immernoch schiefgehen - bei konkurrierenden Updates z.B. … DAS ist das, was ein ordentliches DBMS zu tun hat - mehr nicht.

Was du hier versuchst als “Feature” zu verkaufen darf man eher als Designschwäche von Postgres enttarnen.

Denn wenn du dir mal die Fehlermeldung anschaust, dann wirst du hoffentlich erkennen, dass die TX auch für PG seltsamer weise noch “lebt” aber er einfach keine Kommandos mehr entgegen nimmt - etwas confused …

Nachtrag:
eine TX ist in erster Linie eine Logische Einheit / Logische Zusammenfassung von Änderungen - und eben KEINE technische Funktion. Ein DBMS bietet eine technische Funktion - die man auch Transaktion nennt - um solche TX durchfuehren zu können. Und diese Funktion ist bei Postgres eben NICHT besonders toll gelöst.



Ich wüsste nicht was an einem Syntax Fehler “recoverable” ist.
Ich wüsste erst recht nicht was an fehlgeschlagenen Inserts auch nur im entferntesten “recoverable” ist.


symbiont: Wenn du deine persönliche und unbestätigte Meinung und deine Hitzköpfigkeit endlich mal außen vor lassen würdest könnte man mit die auch vernünftig diskutieren. Aber so lange wie du jeden Thread zum Anlaß nimmst es akretschmer oder mir mal so richtig zeigen zu wollen - bitte schön. Wie mir aus anderer Quelle zugetragen wurde ist das hier wohl nicht das einzige Forum in dem du (bzw. dein Nick) bereits für solche Aktionen bekannt bist.


Zurück zum Thema: SQL Standard erlaubt (may) es der Datenbank auf Fehler so zu reagieren, wie PostgreSQL es tut. Außerdem ist dieses Verhalten vorhersagbar (jeder Fehler führt zum Abbruch der Transaktion bzw. um es für symbiont ganz genau zu schreiben: zum Abbruch der Transaktion seit dem letzten Savepoint) und damit deterministisch. Wenn jemand Applikationen schreiben möchte die mit 95% der eingefügten Daten auskommen - bitte schön, nicht unser Problem. Auch wenn es schwer fällt: Datensicherheit vor Komfort. Dafür wird diese Datenbank von vielen Leuten geschätzt. Wer das nicht haben will darf sich doch bitte eine der hier schon genannten Alternativen aussuchen, ich werde nicht traurig darum sein.

wer redet denn von Syntax Fehlern?

Das tut mir aber leid, dass du nicht weisst das es ein “vor dem Insert” gibt … wie konnten sie bloss SAVEPOINT realisieren - wieder eine Fkt die es garnicht geben kann …

wie es in den Wald schallt :slight_smile: … nimms nicht so ernst …

zum Thema nochmal …

ich kann so recht haben, wie ich will - mit den TX - das bringt mir nix - weil PG davon nicht besser wird - und uns nicht geholfen

Wenn ich auch nur das leiseste Gefühl haette, dass ihr beiden “vernuenfig” Diskutieren wollt, dann liese sich sehr wahrscheilich sogar eine interessante TECHNISCHE Begruendung dafuer liefern, warum PG so funktioniert wie es funktioniert. D.h. ich habe so eine leise Ahnung davon warum es so ist.

Weisst du - wenn ihr sagt “nutzt SAVEPOINT” - ist das eine Sache - Wenn ihr sagt “nutzt SAVEPOINT weil das ist das beste der Welt und alle anderen machen es falsch” kann ich das nicht einfach so stehen lassen. Weil <-DAS Quatsch ist.

Schau mal … SAVEPOINT ist eine Lösung fuer eine Art “subtransactions” … spinnt man diese “Interpretation” mal weiter, dann sehe ich bei DML-Kommando auch lauter subtransactions. Nirgends steht geschrieben, dass das nicht so sein darf. So ziemlich jedes gängige DBMS hat es so umgesetzt - weils naheliegend und nachvollziehbar und eben NICHT FALSCH ist. An anderen Stellen in PG funktioniert es ja auch wunderbar. Ich kann mich immer drauf verlassen, das alles nach dem UPDATE, DELETE, INSERT konsistent ist - egal wieviele Mrd Trigger aufgerufen wurden - weils als TX abgearbeitet wird.

Eure Argumentation ist wie ich schon mehrfach erwähnte auch nicht Konsistent - ihr sagt bei einem Fehler ist die TX per definition ungueltig - wie soll dann SAVEPOINT funktionieren? das ist innerhalb einer TX … es passiert ein Fehler ? In welchen SAVEPOINT der TX soll ich denn zurueckrollen - wenn sie garnichtmehr existieren kann ? siehe oben ?

Gut - es ist aber wie es ist - Performance wäre z.B. ein akzeptables und nachvollziehbares Argument, weil der Aufwand für explizite SAVEPOINTS präsenter ist als ähnlicher (ich manchen fällen gleich grosser) für jede Operation. Dieses Argument haette die gleiche Qualitaet wie der gänzliche Verzicht von TX z.B. bei MyISAM - da sagt auch niemand, weils das beste der Welt ist - alternativ gibts andere table-typen …

so kann man argumentieren …

Wir “spinnen” hier gar nichts. Wir lesen Dokumentation und Standard. Na gut, ich wenigstens, ich denke mir nicht meinen eigenen Teil dazu aus.

Andere Leute haben sich vor 14 Jahren schon dazu Gedanken gemacht und sind zu der Meinung gekommen das Savepoints keine “Subtransaktionen” sondern “Rückkehrpunkte” sind.


So ziemlich jedes gängige DBMS hat es so umgesetzt - weils naheliegend und nachvollziehbar und eben NICHT FALSCH ist.

Überall dort, wo ein “may” im Standard steht, ist das der Implementierung überlassen wie sie das handhabt. Oh, und noch eine Überraschung für dich: große Teile des Standards wurden und werden geschrieben nachdem die Features von den einzelnen Herstellern - natürlich unterschiedlich - implementiert sind. Darum ist der SQL-Standard auch der kleinste mögliche Nenner - aber wir sollten hier trotzdem versuchen uns daran zu halten und uns nicht zusätzlich auch noch unsere eigenen Möglichkeiten auszudenken.



Eure Argumentation ist wie ich schon mehrfach erwähnte auch nicht Konsistent - ihr sagt bei einem Fehler ist die TX per definition ungueltig - wie soll dann SAVEPOINT funktionieren? das ist innerhalb einer TX … es passiert ein Fehler ? In welchen SAVEPOINT der TX soll ich denn zurueckrollen - wenn sie garnichtmehr existieren kann ? siehe oben ?

Ich empfehle dir mal diesen Thread ganz von vorne zu lesen. Savepoints kamen erst später auf, nach Transaktionen. Und hier (das ist schon viele Postings zurück) habe ich bereits an einem Beispiel gezeigt dass SAVEPOINTs sehr wohl funktionieren. Alles andere was du hier zu SAVEPOINTs und irgendwelchen nicht vorhandenen Aussagen von akretschmer oder mir gesagt hast ist frei aus der Luft gegriffen.
Oder anders gesagt: du diskutierst seit zwei Seiten um ein Problem herum das du dir selber geschaffen hast.

Sowohl akretschmer wie ich haben mehrmals darauf hingewiesen das SAVEPOINTs dazu da sind Fehler in Transaktionen abzufangen ohne die komplette Transaktion zu zerstören. Das funktioniert. Wir haben nie etwas anderes behauptet, du unterstellst uns das hier lediglich.

Ach ja, möge bei dir der Eindruck entstanden sein das eine Transaktion ohne Savepoints nur zerstört werden kann: dem ist so. Das betrifft jedoch nur Transaktionen ohne Savepoints, nicht solche mit einem Savepoint. Vielleicht hätten wir das explizit dazuschreiben sollen, das von mir verlinkte Beispiel hat anscheinend zum Nachvollziehen nicht ausgereicht.

bei Postgres …

du sprichst ja sicher von expliziten SAVEPOINTS … nichts hindert einen schlauen implementeur daran die TX auch ohne SAVEPOINTS am leben zu erhalten.

Du haengst immer an deinem SAVEPOINT … ich zweifle nicht daran, dass sie funktionieren

Sie sind auch garnicht das Thema - “subtransaction” stand nicht ohne Grund in Klammern - was machst Du? - versuchst mir einen Strick zu drehen - ne ne …

Also weiter … du sagst TXe M Ü S S E N bei “fehlern” zerstoert werden.

Und ich sage immernoch DAS IST QUATSCH

Ein beispiel direkt vor deiner Nase:
PG behandelt jede DML-Operation als TX - stimmt doch?!
was passiert in einer Trigger-Funktion - die in eine andere Table was aendert - und das schiefgeht:

PostgreSQL: Documentation: Manuals: PostgreSQL 8.2: Error Handling

und nun? Kollabiert das Universum?

Ihr tut beide so als haettet ihr die Weisheit mit Löffeln gefressen - Ihr solltet euch mal beide um etwas bescheidenheit bemuehen!

Selbst der Hinweis, dass inzwischen so ziemlich JEDES andere TX-faehige DBMS es anders Handhabt laesst euch nicht davon abbringen zu behaupten Postgres würde alles richtig machen - und der rest der Welt sei dämlich.

Hallo oliver.schulze,

ich hoffe das dieser Thread, trotz der IMHO teilwiese sehr unseriösen Ausdrucksweise von Symbiont hilfreich für dich wahr.

Als jemand der bereits Anwendungen, wie du, portieren musste kann ich dir sagen, dass die Transaktionen von PG vielleicht etwas ungewöhnlich, aber deutlich einfacher zu handhaben sind.
Wenn deine Applikation sauber strukturiert ist bekommst du kaum Schwierigkeiten, die Änderungen in den Abläufen bzw. den abgesetzten Kommandos dürten nur minimal sein. Nach einer gewissen Zeit wirst du die Anwendung von Savepoints sogar zu schätzen wissen. Datenkonsistenz zu gewährleisten fällt mit PG sehr viel einfacher als unter anderen Datebanken mit denen ich bisher gearbeitet habe.
Ein wenig anpassen muss man ja die meisten Programme von Datenbank zu Datenbank, da fällt das anpassen des Transaktionsmanagments doch weniger ins Gewicht.

Zusammenfassend: PG verhällt sich vielleicht nicht ganz so wie einige andere Datenbanksysteme. Ich persönlich mag die Transaktionstechnik bei PG, da sie mir einige Sorgen abnimmt. Eine der großen Stärken wie ich finde.

Gruß
Sparrow

Ja, danke, hat mir geholfen, PG besser zu verstehen. Wobei ich die Ausdrucksweise von Symbiont mir gegenüber völlig in Ordnung fand. Allerdings: da hab ich durch meine Frage ja eine ganz schöne Diskussion losgetreten :wink:

Wenn du mal lesen und nicht nur für dich interpretieren würdest.

Ich spreche es keinem RDBMS ab Transaktionen anders zu implementieren, warum auch. Nur: du verlangst von PostgreSQL dass das Problem so zu lösen ist wie du es gern haben möchtest. Unter anderem hier, hier, hier, hier, hier, hier, hier und hier, eigentlich in jedem zweiten Posting von dir. Deine unsinnigen Versuche dein rechthaberisches Getue mit großen roten Buchstaben zu untermauern macht das ganze auch nicht glaubwürdiger.
Merkst du was? Wenn du mit PostgreSQL nicht zufrieden bist dann such dir etwas anderes. Wenn du mit der Funktionalität nicht zufrieden bist: bitte schön, jeder darf sich auf der -hackers Mailingliste eintragen und das dort zur Diskussion stellen. Wenn du eine Mehrheit mit deinen Argumenten überzeugst wird das geändert. Versuch es einfach; wenn du vernünftige Argumente bringst und keine großen roten Buchstaben sehe ich das sogar ein. Wenn du dagegen hier nur rumschwallen möchtest …

Bis dahin: akretschmer und ich schreiben zu dem was PostgreSQL ist. Nicht zu dem, was du gerne haben möchtest. Wenn du darin einen Konflikt siehst behalt ihn bitte für dich oder äußere ihn auf der entsprechenden Mailingliste. Wir kümmern uns derweil ob wir vielleicht dem ein oder anderen User helfen können.

jaja halte mich mit unwichtigkeiten auf :slight_smile:

warum gehst du nicht mal aufs wesentliche ein? - dass ihr muell erzaehlt?

PG verhaelt sich naemlich innerhalb bestimmter TX (eine insert-operation - incl. der trigger-fkt und abhaengigen inserts updates etc.)

GENAU SO!!! wie du behauptest, dass es “FALSCH” wäre

lach