Datenbank Wrapper

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Sonntag 4. Dezember 2005, 19:22

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 ^^)
TUFKAB – the user formerly known as blackbird
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 5. Dezember 2005, 08:07

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Montag 5. Dezember 2005, 10:22

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.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 5. Dezember 2005, 10:52

blackbird hat geschrieben: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
blackbird hat geschrieben: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...

blackbird hat geschrieben: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???
blackbird hat geschrieben: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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
raist1314
User
Beiträge: 52
Registriert: Dienstag 21. September 2004, 06:58
Wohnort: Adelzhausen
Kontaktdaten:

Montag 5. Dezember 2005, 11:11

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
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 5. Dezember 2005, 11:14

raist1314 hat geschrieben:allerdings hats da einige blöde Limitierungen
Kannst du das näher Ausführen???

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Montag 5. Dezember 2005, 17:02

So. Aktuelle Version ist oben. __del__ wurde gekillt und persitent isses trotzdem noch ^^.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 5. Dezember 2005, 19:40

blackbird hat geschrieben:So. Aktuelle Version ist oben.
URL wäre nicht schlecht: http://trac.pocoo.org/browser/trunk/pocoo/database.py :wink:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 5. Dezember 2005, 19:52

jens hat geschrieben:URL wäre nicht schlecht
URL hat sich ja nicht geändert :wink:
My god, it's full of CARs! | Leonidasvoice vs Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Montag 5. Dezember 2005, 22:02

blackbird hat geschrieben:...Aktuell frage ich mich ob es sinnvoll ist, wirklich jedesmal pro Request eine Verbindung fix zu öffnen (an cgi denk ^^) ...
blackbird hat geschrieben:...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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 6. Dezember 2005, 16:00

tabellar hat geschrieben:Etwas komplex, aber dafür eine saubere Architektur ... ;-)
Ich glaube nicht, dass es wesentlich komplexer als SQLator werden kann ;)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Samstag 17. Dezember 2005, 21:38

Hi blackbird,

ich hab auf trac.pocoo.org deine dbApi Änderungen mitverfolgt :wink: .
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
Antworten