Datenbank Wrapper

[mitsuhiko]

Ihr Datenbankprofis ^^

http://trac.pocoo.org/browser/trunk/pocoo/database.py

Ist dieser Weg sinnvoll? Wenn nein, was hättet ihr zu bieten? Mir fäll nicht wirklich was besseres ein.
Aktuell frage ich mich ob es sinnvoll ist, wirklich jedesmal pro Request eine Verbindung fix zu öffnen (an cgi denk ^^)

[jens]

Hm! Das verstehe ich allerdings nicht unter einem Wrapper... Ich denke ein Wrapper sollte eine Einheitliche Schnittstelle bilden, wie z.B. mein MySQL-Wrapper:
http://www.jensdiemer.de/Programmieren/ ... db_wrapper
der bietet immerhin eine einfache Schnittstelle zu den SQL-"Grundbefehlen", wie SELECT, UPDATE, INSERT usw.
Damit hab ich bei PyLucid schon mal 90% aller SQL-Befehle abgedeckt... Wenn man "komplizierte" SQL-Statements ausführen will, kann man direkt an's cursor-Objekt gehen...

Was verstehst du unter "fix zu öffnen" ???
Bei CGI kann man nix anderes machen, als bei jedem Request ein connect zur DB aufzubauen und am Ende wieder zu schließen...

[mitsuhiko]

Hiho,

Hab mir gerade deine Version angesehen, die schaut auch schon ganz gut aus, aber leider unterstützt sie kein Postgres und auch nur pysqlite2.

Aber unter einem Wrapper verstehe ich einfachen Zugriff auf die Datenbankverbindungen und keine Funktionen für SELECT und co.

Die Idee ist es ein Datenbank Objekt zu haben und die User, Forum, Topic, Post Tabellen als Objekte implementiert. Wenn ich zu Hause bin lade ich die aktuelle Version hoch, damit man sich etwas darunter vorstellen kann.

Mit fix öffnen stell ich mir das so vor. Alle Datenbankobjekte haben eine gemeinsame Verbindung. Wenn der Request geöffnet wird überprüft die connect Funktion ob eine Verbindung existiert (bei mod_python und co von einem früheren Request), für CGI macht es eine neue Verbindung.

Wenn die letzte Instanz beendet wird (__del__) überprüft er, ob eine persitente Verbindung gewüscht wird und hält sie offen, ansonten beendet er sie.

[jens]

Hab mir gerade deine Version angesehen, die schaut auch schon ganz gut aus, aber leider unterstützt sie kein Postgres und auch nur pysqlite2.

Da bin ich dabei es nachzuholen: http://pylucid.python-hosting.com/file/ ... m/mySQL.py

Aber unter einem Wrapper verstehe ich einfachen Zugriff auf die Datenbankverbindungen und keine Funktionen für SELECT und co.

Naja, vielleicht kann man das in zwei Teile aufspalten... Nur die Python DB-API ist ja schon eine Einheitliche Schnittstelle... Nur der connect ist evtl. etwas anders, je nach DB...

Die Idee ist es ein Datenbank Objekt zu haben und die User, Forum, Topic, Post Tabellen als Objekte implementiert.

Ja, du wolltest dafür ja SQLObjekt nutzten... Aber ich bin mir da nicht sicher, ob SQLObjekt so das non-plus-ultra ist (Wobei das mein Wrapper sicherlich auch nicht ist) ... Es ist halt die Frage, in wiefern SQLObject einen Overhead produziert, denn man nicht hat, wenn man direkt an die DB geht...
Man muß halt mal SQLObjekt näher teste... Gib es irgendwo schon halbwegs aufwendige Szenarien wü SQLObject erfolgreich angewendet wurde???

Mit fix öffnen stell ich mir das so vor. Alle Datenbankobjekte haben eine gemeinsame Verbindung. Wenn der Request geöffnet wird überprüft die connect Funktion ob eine Verbindung existiert (bei mod_python und co von einem früheren Request), für CGI macht es eine neue Verbindung.

Wenn die letzte Instanz beendet wird (__del__) überprüft er, ob eine persitente Verbindung gewüscht wird und hält sie offen, ansonten beendet er sie.

So hab ich es im prinzip bei PyLucid gemacht. Fast ganz am Anfang wird mein Wrapper Instanziert und connected und die Klasse wird als Objekt überall durchgerecht (ähnlich wie deine environ-Lösung) ganz zum Schluß, wenn die Seite komplett aufgebaut wurde. Wird die Verbindung "per Hand" beendet...
Irgendwie über __del__ zu gehen ist vielleicht aber auch ganz nett...

[raist1314]

Ich weiss nicht ob,es sinnvoll ist, __del__ zu benutzen, da __del__ erst dann ausgeführt wird, wenn der GC das Objekt aufräumt und darauf hat man keinen Einfluss.

Im übrigen ist der SQLObject Ansatz sicher nicht verkehrt, allerdings hats da einige blöde Limitierungen, sonst hätt ich es sicher in einem meiner Projekte schon verwendet... Ich mach mir aber noch mal nen paar Gedanken...

Gruss

Sebastian

[jens]

allerdings hats da einige blöde Limitierungen

Kannst du das näher Ausführen???

[mitsuhiko]

So. Aktuelle Version ist oben. __del__ wurde gekillt und persitent isses trotzdem noch ^^.

[jens]

So. Aktuelle Version ist oben.

URL wäre nicht schlecht: http://trac.pocoo.org/browser/trunk/pocoo/database.py

[Leonidas]

URL wäre nicht schlecht

URL hat sich ja nicht geändert

[tabellar]

...Aktuell frage ich mich ob es sinnvoll ist, wirklich jedesmal pro Request eine Verbindung fix zu öffnen (an cgi denk ^^) ...

...Aber unter einem Wrapper verstehe ich einfachen Zugriff auf die Datenbankverbindungen und keine Funktionen für SELECT und co.

Die Idee ist es ein Datenbank Objekt zu haben und die User, Forum, Topic, Post Tabellen als Objekte implementiert. Wenn ich zu Hause bin lade ich die aktuelle Version hoch, damit man sich etwas darunter vorstellen kann.

Mit fix öffnen stell ich mir das so vor. Alle Datenbankobjekte haben eine gemeinsame Verbindung. Wenn der Request geöffnet wird überprüft die connect Funktion ob eine Verbindung existiert (bei mod_python und co von einem früheren Request), für CGI macht es eine neue Verbindung.

Ich sehe hier mehrere Fragen. Zum einen geht es Dir um die Verwaltung
von DB connections und zum anderen um einen gekapselten (wrapper)
Objektzugriff auf (persistente) DB Objekte (Forum, Post, etc. ).

Ein Ansatz zur Lösung ist das ganze in einer Persistenz Komponente
(PersistenceManager PM) zu integrieren. Der PM stellt eine definierte
Schnittstelle für (optimierte) Abfragen (QueryMgr) sowie eine Schnittstelle
für das Anlegen, Bearbeiten und Löschen von Objekten (PoolMgr) zur
Verfügung. Der oder die PoolMgr (Factory) besitzen immer eine DB
Connection, die der ConnectionMgr herstellt und überwacht. Das
Bindeglied zwischen den Objekten des PoolMgrs und dem DB Schema ist
dann ein sogenannte MappingMgr, der für die Transformation beider
Welten zuständig ist.

Etwas komplex, aber dafür eine saubere Architektur ...

Tabellar

[Leonidas]

Etwas komplex, aber dafür eine saubere Architektur ...

Ich glaube nicht, dass es wesentlich komplexer als SQLator werden kann

[tabellar]

Hi blackbird,

ich hab auf trac.pocoo.org deine dbApi Änderungen mitverfolgt .
Gleichzeitig habe ich jetzt auch eine DB Zugriffsschicht erstellt
[PYPERCOM], wo ich die Ideen von oben umgesetzt habe. Vielleicht
ist es für Dich ja interessant.

Tabellar