/blog/wvk

Wie schon vor einiger Zeit in diesem Eintrag beschrieben, bietet Consolvix eine durchaus ausgeklügelte Möglichkeit, Transaktionen über mehrere Schritte zu implementieren. Gestern Nacht kamen mir kurz vorm Einschlafen dazu noch zwei Ideen, die ich vielleicht noch umsetzen möchte (hier wäre mir die Meinung eines Experten sehr willkommen).

1. Momentan speichere ich die Daten zu einer Transaktion als YAML serialisiert im data-Feld einer ConsolvixTransaction ab. Wird die Transaktion abgebrochen, werden alle temporären Daten also gelöscht und gut ist. Aber eigentlich, ja EIGENTLICH, ist das ja nicht ganz sauber -- wenn man doch ein User-Objekt hat, und sei es nur ein temporäres, dann gehört das ja eigentlich in die users-Tabelle und in der Transaktion sollte nur die ID und der Typ des Objektes gespeichert werden. Wenn dann die Transaktion gelöscht wird, sollten diese temporären Objekte ebenfalls gelöscht werden. An sich kein Problem, ich bin mir sogar sicher, dass sich das äußerst elegant über HABTM und polymorphische Aggregation lösen ließe. Aber: So lange die Transaktion nicht abgeschlossen ist, befinden sich also unter den "gültigen" Objekten auch "ungültige", also solche, die überhaupt noch nirgends in der restlichen Applikation auftauchen sollten! Also müsste dann doch irgendwie jedes temporäre Objekt als solches markiert werden -- und dann hört die Sache wieder auf, elegant zu sein -- ganz im Gegenteil gar. Dabei sei angemerkt, dass theoretisch jede Entität (aus 20, 30, vielleicht auch irgendwann mal über 50 möglichen) in einer Transaktion vorkommen kann. Also doch lieber bei der jetzigen Methode (also dump/serialisieren) bleiben? Wie werden solche vorläufigen Daten in Businessapplikationen "der Großen" gehandhabt? Hilfe...?
2. "Points of no Return" einbauen. Bitte was? Gerade bei Webhosting-Angelegenheiten gibt es Aktionen, die die Bestätigung des Benutzers/Kunden erfordern. Beispiel: neue Bestellung, bestehend aus vier Schritten. Schritt 1: Kunde wählt z.B. "5GB mehr Speicher". Schritt 2: Kunde bestätigt Bestellung und erklärt sich mit irgendwelchen Bedingungen einverstanden. Dann wird eine E-Mail an die Buchhaltung geschickt, diese bestätigt Schritt 3, sprich "Kunde bekommt nun 5 GB Speicher mehr abgerechnet". Dann wird eine E-Mail an den Admin geschickt, dieser bestätigt Schritt 4, dass die 5 GB auch tatsächlich freigeschaltet werden. Diese Transaktion hätte zwei "Points of no return": Nachdem der Kunde Schritt 2 bestätigt hat, kann er nicht mehr zu Schritt 1 zurück, was mit der aktuellen Transaktionsverwaltung aber jederzeit möglich wäre. Der zweite PonR wäre, nachdem die Buchhaltung ihren Teil bestätigt hat -- danach kann auch nicht mehr zu Schritt 3 zurückgesprungen werden, sondern entweder der Admin bestätigt auch Schritt 4, oder er bricht die ganze Transaktion ab und alles bleibt beim alten. Ein anderes Beispiel wäre z.B. das Registrieren eines neuen Accounts: der potentielle Kunde füllt drei Seiten Formularkram aus, schickt diese ab und kann danach nichts mehr an Schritt 1..3 ändern, auch wenn die Transaktion an sich erst abgeschlossen ist, wenn die Buchhaltung und der Admin (kann meinetwegen die gleiche Person sein) noch ihre 1...n Schritte abgeschlossen haben. Mir scheint es eigentlich sinnvoll und durchaus elegant, neben der Definition einer Sequenz von Actions als Schritte in einer Transaktion auch "Synchronisationspunkte" zu definieren, nach denen entweder abgebrochen oder weitergemacht, nicht aber zurückgesprungen werden kann. Wird das bei Datenbanktransaktionen nicht auch im Grunde genommen so verwendet? Stating the obvious? Denke ich nun wieder zu kompliziert? Meinungen? Buh-Rufe? Faule Eier?

Jedenfalls kommen noch weitere Änderungen an der bestehenden Transaktions-API hinzu, weil ich gemerkt habe, dass sich noch einige Komplifikationen ergeben, sobald verschiedene Teile einer Transaktion von unterschiedlichen Benutzern (teilweise noch nicht einmal vorhandenen!) ausgeführt werden können müssen.

...

und ich glaube, Deutsch ist tatsächlich die einzige Sprache, in der vier aufeinander folgende Verben ein grammatikalisch korrektes Konstrukt bilden können... ;-)