SIG zur Entwicklung von Persistenz- und Transaktionsframeworks

Aktuelle Neuigkeiten

Auf der O'Reilly Open Source Conference findet ein Python Persistence BOF statt.

Python-Persistenz
Datum: 25.07.2002
Uhrzeit: 20:00 - 22:00 Uhr
Ort: Grande Ballroom C im East Tower
Moderation: Patrick O'Brien, Orbtech

Eine Python Persistence Special Interest Group (SIG) wurde kürzlich gegründet, um Wege zu erkunden, grundlegende Persistenz- und Transaktionsmechanismen in den Kern von Python zu integrieren, um die doppelte Arbeit verschiedener Projekte mit ähnlichen Problemen zu vermeiden. Dieses BOF ermöglicht es den Teilnehmern, über die Python-Persistenz persönlich nachzudenken. Darüber hinaus sind alle, die an einer informellen Frühstücksdiskussion über Python-Persistenz mit Jim Fulton und Guido van Rossum interessiert sind, herzlich eingeladen, am Mittwochmorgen um 7 Uhr im O'Reilly Food Tent teilzunehmen.

Charta

Problem

Es laufen eine Reihe von Projekten zur Bereitstellung von Persistenzmechanismen für Python. Diese Bemühungen haben eine Reihe gemeinsamer Anforderungen, darunter:

Transparenz: Anwendungen müssen nicht explizit Objektänderungen verfolgen oder Objekte speichern. Anwendungen müssen die meisten Objekte nicht explizit abfragen. Typischerweise werden einige "Root"-Objekte explizit abgerufen und andere Objekte durch normale Python-ObjektTraversal abgerufen. Anwendungsobjekte sollten keinen SpeicherCode enthalten, wie z. B. SQL-Anweisungen oder DateiOperationen, die zur Bereitstellung ihrer Persistenz erforderlich sind. Anwendungscode muss möglicherweise Code zur Generierung von Persistenz-bezogenen Ereignissen enthalten, aber selbst diese sollten so weit wie möglich automatisiert werden, z. B. durch Überwachung von Attributzugriffen.
Transaktionaler Speicher: Daten sollten transaktional mit Unterstützung für das Zurückrollen von Änderungen gespeichert werden. Unterstützung für (optionale) verschachtelte Transaktionen sollte erwartet werden.
Effektive Speichernutzung: Anwendungen sollten keine übermäßige Speichermenge verbrauchen. Oft verwenden Persistenzanwendungen Datenbanken, die zu groß sind, um in den Speicher zu passen. Objekte sollten nur geladen werden, wenn sie notwendig sind, und aus dem Speicher entfernt werden, wenn sie nicht mehr benötigt werden.

Die meisten dieser Bemühungen konzentrieren sich auf die Bereitstellung von Persistenz unter Verwendung relationaler Datenbankdaten. Die Bemühungen schreiten größtenteils unabhängig voneinander voran. Jede wird versuchen, die oben genannten Anforderungen unabhängig zu erfüllen, mit viel doppelter Arbeit.

Die Zope Object Database (ZODB) erfüllt die oben genannten Anforderungen seit einiger Zeit. ZODB durchläuft derzeit einen Übergang von ZODB 3, das auf ExtensionClass basierte, zu ZODB 4, das auf Python 2.2 new-style classes basiert. Als Teil dieser Bemühungen werden die ZODB-Persistenz- und Transaktionsframeworks aus ZODB in separate Pakete ausgegliedert, in der Hoffnung, dass sie für andere persistenzbasierte Frameworks nützlich sein werden.

Es wäre eine enorme doppelte Arbeit, wenn jedes der verschiedenen Persistenzprojekte die oben genannten Anforderungen unabhängig erfüllen müsste. Schlimmer noch, die resultierenden Systeme hätten unabhängige Frameworks, die wahrscheinlich nicht miteinander interoperieren würden. Objekte, die für ein Framework erstellt wurden, müssten neu geschrieben werden, um mit einem anderen zu funktionieren.

Vorschlag

Eine neue Persistence-SIG wird vorgeschlagen, um Persistenz- und Transaktionsframeworks zu erforschen und, wenn möglich, zu produzieren, die für eine Vielzahl von Persistenzimplementierungen verwendet werden können, einschließlich relationaler datenbankbasierter Persistenz und ZODB.

Koordinator: Jeremy Hylton

Schlussfolgerung: Wenn Version 1.0 der Frameworks ausgeliefert wird, oder am 1. September 2003, je nachdem, was früher eintritt.

Ergebnisse: PEPs, die die erstellten Frameworks dokumentieren, und Software, die Schlüsselkomponenten der Frameworks implementiert.

Unter der Annahme, dass ein zufriedenstellendes Framework definiert werden kann, sollten das Framework und die Kernimplementierungen in Standard-Python-Distributionen enthalten sein.

Umfang

Der Umfang dieser SIG umfasst gemeinsame Frameworks für

Transaktionskoordination
Grundlegende Persistenzverwaltung, insbesondere Beobachtung von Objektänderungen (um zu wissen, wann ein Objekt gespeichert werden muss) und Zugriff (um zu wissen, wann Objekte verwendet werden, damit ungenutzte Objekte aus dem Speicher entfernt werden), und
Aktivierung und Caching, um Objekte bei Bedarf in den Speicher und bei Nichtbedarf aus dem Speicher zu verschieben.

Der Umfang umfasst *nicht*

Konkurrenzkontrolle. Dies ist die Verantwortung spezifischer Datenmanager, die in die Frameworks integriert sind. Der Transaktionsmanager verfolgt lediglich Objektänderungen und koordiniert die Aktivitäten der Datenmanager, um Änderungen atomar zu committen (oder zurückzurollen).
Abfragesprachen. Einzelne Datenmanager oder Anwendungen können Abfragefunktionen bereitstellen. Obwohl es cool wäre, eine gemeinsame Abfragefunktion für Python zu haben, und ich ein solches Projekt unterstützen würde, wäre dies ein anderes Projekt als dieses.
Integritätsbeschränkungen. Einige Datenmanager, wie z. B. solche, die auf relationalen Daten basieren, müssen Einrichtungen für niedrigstufige Integritätsprüfungen bereitstellen, während andere, wie z. B. ZODB, dies nicht tun. Ebenso ist die Speicherbereinigung die Verantwortung des Datenmanagers, nicht des Frameworks. Integritätssysteme auf Anwendungsebene wären ebenfalls interessant, würden aber nicht von einem Persistenzsystem abhängen.