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 ^^)
Datenbank Wrapper
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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...
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...
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
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.
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
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Da bin ich dabei es nachzuholen: http://pylucid.python-hosting.com/file/ ... m/mySQL.pyblackbird 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.
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:Aber unter einem Wrapper verstehe ich einfachen Zugriff auf die Datenbankverbindungen und keine Funktionen für SELECT und co.
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...blackbird hat geschrieben:Die Idee ist es ein Datenbank Objekt zu haben und die User, Forum, Topic, Post Tabellen als Objekte implementiert.
Man muß halt mal SQLObjekt näher teste... Gib es irgendwo schon halbwegs aufwendige Szenarien wü SQLObject erfolgreich angewendet wurde???
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...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.
Irgendwie über __del__ zu gehen ist vielleicht aber auch ganz nett...
-
- User
- Beiträge: 52
- Registriert: Dienstag 21. September 2004, 06:58
- Wohnort: Adelzhausen
- Kontaktdaten:
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
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
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
URL wäre nicht schlecht: http://trac.pocoo.org/browser/trunk/pocoo/database.pyblackbird hat geschrieben:So. Aktuelle Version ist oben.
blackbird hat geschrieben:...Aktuell frage ich mich ob es sinnvoll ist, wirklich jedesmal pro Request eine Verbindung fix zu öffnen (an cgi denk ^^) ...
Ich sehe hier mehrere Fragen. Zum einen geht es Dir um die Verwaltungblackbird 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.
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
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich glaube nicht, dass es wesentlich komplexer als SQLator werden kanntabellar hat geschrieben:Etwas komplex, aber dafür eine saubere Architektur ...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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
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