Hallo, ich schnueffle gerade in SQLite und seiner Python-Huelle herum. Von der Verpackung her zu urteilen (man muss sich, zumindest auf OS X und bei SQLite, noch ein wenig "die Finger schmutzig" machen) wuerde ich sagen: so ultra-robust ist es vielleicht noch nicht, oder? Aber der Inhalt kann ja durchaus besser sein, als die Ver- packung... ;-) PySQLite hat es da, natuergemaess, leichter, wenngleich man sich dabei auch z.B. nicht unbedingt wuenscht, die Doku selbst bauen zu muessen, zumal man dazu Links auf private Python-Interpreter aendern muss, etc... Daher also die Fragen: wie aktiv wird an diesen Paketen gearbeitet, was ist zu erwarten, wer hat welche Erfahrungen damit gemacht? Ist die API speziell von PySQLite kompatibel zum Python-Datenbank- Interface? Wozu taugt (Py)SQLite definitiv nichts? Immerhin ist Gerhard Haering von dieser Liste einer der Betreuer von PySQLite. Danke, Dinu PS: http://www.sqlite.org http://pysqlite.sourceforge.net -- Dinu C. Gherman ...................................................................... "We will accept no output except complete victory." ("President" George W. Bush, 2003) "Do you believe... in the final total victory?" (Joseph Goebbels, 1943) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo, ich habe auch gerade begonnen mit SQlite (PySQLite) zu hantieren. Mein erster Eindruck (win32) laeuft stabil und zum erzeugen dynamischer Webseiten (auf Basis von twisted-woven) durchaus zu gebrauchen (schnell). Was mich an dem Thema reizt ist: - etwas groesser als 210 K - Python DB-Api 2.0 - Trigger (INSTEAD OF) Ich teste den Vergleich mit Oracle. Bei der Anwendung sind die ennormen Moeglichkeiten von Oracle nicht alle notwendig. Ich werde mal beim Abschluss des Projektes weitere Eindruecke verlauten lassen. schoene Gruesse Martin -----Ursprüngliche Nachricht----- Von: python-de-bounces@python.net [mailto:python-de-bounces@python.net] Im Auftrag von Dinu Gherman Gesendet: Montag, 25. August 2003 18:23 An: python-de@python.net Betreff: [Python-de] PySQLite-Erfahrungen? Hallo, ich schnueffle gerade in SQLite und seiner Python-Huelle herum. Von der Verpackung her zu urteilen (man muss sich, zumindest auf OS X und bei SQLite, noch ein wenig "die Finger schmutzig" machen) wuerde ich sagen: so ultra-robust ist es vielleicht noch nicht, oder? Aber der Inhalt kann ja durchaus besser sein, als die Ver- packung... ;-) PySQLite hat es da, natuergemaess, leichter, wenngleich man sich dabei auch z.B. nicht unbedingt wuenscht, die Doku selbst bauen zu muessen, zumal man dazu Links auf private Python-Interpreter aendern muss, etc... Daher also die Fragen: wie aktiv wird an diesen Paketen gearbeitet, was ist zu erwarten, wer hat welche Erfahrungen damit gemacht? Ist die API speziell von PySQLite kompatibel zum Python-Datenbank- Interface? Wozu taugt (Py)SQLite definitiv nichts? Immerhin ist Gerhard Haering von dieser Liste einer der Betreuer von PySQLite. Danke, Dinu PS: http://www.sqlite.org http://pysqlite.sourceforge.net -- Dinu C. Gherman ...................................................................... "We will accept no output except complete victory." ("President" George W. Bush, 2003) "Do you believe... in the final total victory?" (Joseph Goebbels, 1943) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gherman wrote:
Hallo,
ich schnueffle gerade in SQLite und seiner Python-Huelle herum. Von der Verpackung her zu urteilen (man muss sich, zumindest auf OS X und bei SQLite, noch ein wenig "die Finger schmutzig" machen)
Heisst was? Irgendwelche konkreten Verbesserungsvorschläge für PySQLite?
wuerde ich sagen: so ultra-robust ist es vielleicht noch nicht, oder? Aber der Inhalt kann ja durchaus besser sein, als die Ver- packung... ;-)
PySQLite hat es da, natuergemaess, leichter, wenngleich man sich dabei auch z.B. nicht unbedingt wuenscht, die Doku selbst bauen zu muessen, zumal man dazu Links auf private Python-Interpreter aendern muss, etc...
Problem ist bekannt. Liegt am Dokumentationsformat (Python/LaTex) und ich wüsste nicht, wie man das viel besser lösen könnte. Da ich die Doku selber nicht geschrieben habe und auch LaTex nicht kann, steht evtl. mal ein Umstieg auf z. B. Docbook (kann ich halbwegs) oder ReSt an. Docbook ist von der Toolchain nicht unbedingt weniger krampfig als Python/LaTex, also würde es wohl ReSt werden. Oder einfach OpenOffice :)
Daher also die Fragen: wie aktiv wird an diesen Paketen gearbeitet, was ist zu erwarten, wer hat welche Erfahrungen damit gemacht?
An PySQLite 0.4.x wird so aktiv gearbeitet, wie es nötig ist :) Es sind seit Ewigkeiten von Benutzern keine Bugs mehr gefunden worden, die ich nicht bereits zuvor im CVS gefixt hätte. Also ist es wohl relativ stabil ;-) 0.4 ist für mich der stabile Branch, an dem auch nur noch Bugfixes einfliessen werden. 0.5 wird eine komplette Neuentwicklung von PySQLite werden, und ich bin momentan noch am Experimentieren. Das Ziel ist bestmögliche Performance, weil das für einige Anwendungsbereiche nötig ist. Das heisst im Umkehrschluss übrigens nicht, dass die jetzige Implementierung zu langsam ist. Ich tendiere im Moment dazu, alles in PyRex neu zu schreiben und das PgResultSet, das ich aus pyPgSQL importiert habe, durch db_row [1] zu ersetzen.
Ist die API speziell von PySQLite kompatibel zum Python-Datenbank- Interface?
Ein Plus von PySQLite ist m. E. nach die ziemlich umfangreiche Testsuite. Es gibt momentan 114 Tests, wovon sich auch ein paar mit der DB-API befassen. Ansonsten kann ich sagen, dass PySQLite relativ kompatibel zu pyPgSQL ist (wurde ja viel davon geklaut) ;-)
Wozu taugt (Py)SQLite definitiv nichts?
Ich persönlich würde es nicht für Webprojekte oder allgemein Multiuserprojekte einsetzen (wenn ich so was mache, hab ich vernünftige Server mit Apache+PostgreSQL). Was scheinbar andere Leute nicht davon abhält, das relativ erfolgreich zu tun (z. B. PyPI auf python.org). Ich hab für diesen Anwendungsbereich mittlerweile auch die relevanten SQLite Funktionen gewrappt. Im einfachsten Fall übergibst du beim .connect einfach einen Timeout-Parameter: cx = sqlite.connect("c:/tmp/db", timeout=5000) # 5 Sekunden Timeout Da SQLite auf eine Datei zugreift, wird diese bei Schreiboperationen bzw. Transaktionen komplett gesperrt. Solange diese Transaktion offen ist, kann kein anderer Prozess auf diese Datenbank zugreifen, auch nicht lesend. Der timeout-Parameter gibt an, wie lange maximal gewartet werden soll, bis die Sperre auf die Datei freigegeben worden ist. Nach dem Timeout gäbe es dann was Lustiges wie "_sqlite.OperationalError: database is locked". Allgemein sind längere Transaktionen bei einer "richtigen" Multiuserdatenbank kein Problem, wärend man bei (Py)SQLite da aufpassen muss.
Immerhin ist Gerhard Haering von dieser Liste einer der Betreuer von PySQLite.
Ich bin de-fakto seit einem Jahr der einzige Maintainer :-D -- Gerhard _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerhard Häring:
Gherman wrote:
Hallo, ich schnueffle gerade in SQLite und seiner Python-Huelle herum. Von der Verpackung her zu urteilen (man muss sich, zumindest auf OS X und bei SQLite, noch ein wenig "die Finger schmutzig" machen)
Heisst was? Irgendwelche konkreten Verbesserungsvorschläge für PySQLite?
Heisst, man muss irgendwelche "vorbereiteten" Dateien von Hand ueber- setzen und installieren (sqlite_source.zip), weil der offizielle Weg per make des normalen "tar-balls" nicht tut (sqlite-2.8.6.tar.gz). Aber das liegt natuerlich allein an SQLite...
PySQLite hat es da, natuergemaess, leichter, wenngleich man sich dabei auch z.B. nicht unbedingt wuenscht, die Doku selbst bauen zu muessen, zumal man dazu Links auf private Python-Interpreter aendern muss, etc...
Problem ist bekannt. Liegt am Dokumentationsformat (Python/LaTex) und ich wüsste nicht, wie man das viel besser lösen könnte. Da ich die Doku selber nicht geschrieben habe und auch LaTex nicht kann, steht evtl. mal ein Umstieg auf z. B. Docbook (kann ich halbwegs) oder ReSt an. Docbook ist von der Toolchain nicht unbedingt weniger krampfig als Python/LaTex, also würde es wohl ReSt werden. Oder einfach OpenOffice :)
Den Pfad des Standard-Python-Interpreters sollte man im Makefile zur Laufzeit herausfinden koennen. Dann laeuft alles prima durch, wenn man LaTeX installiert hat. Wenn nicht, sollte man z.B. die PDF- Dateien herunterladen koennen, was aber nicht der Fall ist. Aus ReST kann man auch sehr ansehnliche PDFs generieren (auch ueber LaTeX), plus XML/HTML... Docbook waere nur eine andere Kanone (statt LaTeX).
Ein Plus von PySQLite ist m. E. nach die ziemlich umfangreiche Testsuite. Es gibt momentan 114 Tests, wovon sich auch ein paar mit der DB-API befassen. Ansonsten kann ich sagen, dass PySQLite relativ kompatibel zu pyPgSQL ist (wurde ja viel davon geklaut) ;-)
Habe da mal reingeschaut. Die Testsuite kann man im Code-Umfang noch ziemlich abspecken (bei gleichzeitiger Verbesserung der Lesbarkeit), ohne dass Funktionalitaet verloren geht - von Docstrings mal ganz zu schweigen. Ich wuerde auch die Dateien test_*.py nennen, was ich les- barer finde, aber das ist wohl Geschmackssache. Ein paar Performanz- tests sollte man auch reinnehmen, die evtl. sogar Testdatenbanken im Hintergrund online herunterladen koennten.
Ich bin de-fakto seit einem Jahr der einzige Maintainer :-D
Have a lof of fun, then! ;-) Wie sieht's uebrigens aus mit Interoperabilitaet, d.h. Migration von und nach anderen Datenbanken, z.B. MySQL, PostgreSQL, Oracle, Gadfly? Oder ist das eine reine SQLite-Frage? Und Python-Adapter fuer ODBC und ZopeDB? Gruss, Dinu -- Dinu C. Gherman ...................................................................... "There comes a point when we the people must demand more of our elected officials than just showing up." (Arnold Schwarzenegger) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (3)
-
Dinu Gherman -
Gerhard Häring -
Martin.Moellenbeck＠t-online.de