Wie eine DB mit Installations-Daten füttern?

[jens]

In PyLucid mache ich das z.Z. die Installation so: Es gibt einen SQL-Dump, den ich einfach einspiele. Den Dump erzeuge ich selber mit PyLucid, mit einer lokalen Installation.
So kann ich lokal in den Tabellen Daten ändern, erzeuge eine neuen Dump und hab eine neue Installations-Dump-Datei fertig.

Der Dump ist so aufgebaut, das pro Tabelle eine Dump-Datei (*.sql) in einem ZIP-Archiv zusammen gepackt ist. So kann man einfach im _install-Bereich gezielt nur bestimmte Tabellen in den Installations-Zustand rücksetzten.

Das ganze funktioniert eigentlich ganz gut, ist aber umständich und DB abhängig. Das ist der Grund, warum PyLucid noch nicht statt mit MySQL mit SQLite läuft.

Ich hab außerdem vor, SQLAlchemy einzusetzten und frage mich, ob es nicht damit eine bessere Möglichkeit gibt...

Irgend eine Idee?

[jens]

Wie, da hat keiner eine Idee zu?

[murph]

wenn schon sonst niemand was schreibt:
wieso unterteilst du die dumps? ich hoffe, dann besser das problem zu verstehen.
an sich würde ja sogar eine einfach db mit keyword ausreichen. wieso denn sql für eine installation? du wirst doch nicht flexibel nach einzelnen einstellungen suchen müssen und dann deren namen herausfinden
un dwie gesagt, ich verstehe nicht, wieso du die einzelnen rubriken auf einzelne files unterteilst. sind die so groß, dass es sonst zu langsam wäre?

[jens]

Das unterteilen ist schon ok... So kann ich recht einfach ein "Reinit" von bestimmten Tabellen realisieren: Bei PyLucid gibt es im Install-Bereich die möglichkeit einzelne Tabellen einfach auf Installations-Stand zurück setzten.

Das eigentliche Problem ist jedoch: Der MySQL Dump ist nicht SQLite kompatibel.

Zum Beispiel "AUTO_INCREMENT" wird bei SQLite über PRIMARY_KEY gemacht: http://www.python-forum.de/topic-4029.html

Also ist der SQL-Dump nicht gerade die optimale Lösung Nun könnte ich natürlich einen seperaten SQLite Dump anlegen. Aber das ist mir zu Aufwendig.

Naja, vielleicht ist auch hier SQLAlchemy die Lösung um die Tabellen zu erzeugen???

[murph]

abstraction layer basteln^^
oder eine kleine datenbank wie sqlite oder snakesql einbauen und die verbindlich benutzen.
sobald du dem user die freie datenbankwahl lässt, müsstest du halt verschiedene dumps haben(für jede "eigenartige" datenbank eine).
aber das willst du ja nicht...

[Y0Gi]

Kannst du nochmal konkret deine Frage und dein angestrebtes Ziel herausstellen?

[murph]

kann ich auch:
er will einen universellen dump. der soll auf alle datenbanken passen,
da er sich bei seinem web-projekt nicht festlegen möchte.

[jens]

Jup, so in etwa

Also ich überlege, ob ich nicht die Tabellen-Logik in SQLAlchemy hinterlege. So sollte man mit jeder DB, die SQLAlchemy kann, die Tabellen erzeugen können...

Die Grunddaten müßte ich dann am besten aber auch in einem DB unabhängigen Format haben... CSV???

Wobei die INSERT ja doch immer funktionieren sollten, wie z.B. der hier:

Code: Alles auswählen

INSERT INTO `$$template_engines` VALUES (1,'None'),(2,'string formatting'),(4,'jinja');

[murph]

also csv fand ich bei snakesql sehr gut eingebunden, nur wird das leider zur zeit nicht weiterentwickelt (vielleicht werde ich mich mal daransetzen).
sonst denke ich auch, dass es sehr flexibel ist, wenn man sich sonst die binätdateien ansieht, mit denen man eig nichts anfangen kann (meine meinung).

[jens]

Ich frage mich gerade wie es MoinMoin oder Trac machen... In beiden Wiki's gibt es ja auch Default-Seiten... Weiß jemand spontan, wie die das verwalten?

Oder weiß jemand, ob in SQLAlchemy auch sowas wie ein DB unabhängiges SQL-Dump gibt???

Nochmal zur klarstellung, in PyLucid mache ich das so: Ich habe eine lokale "Test"-Installation. An der kann ich die Tabellen ändern, die Grundseiten editieren und dann erzeuge ich mit dem MySQLdump-Plugin eine neue "Install-ZIP". Diese pack ich zum Source-Archiv dabei und fertig. Der "Installer" nutzt die Daten aus dem ZIP.

Eine spontane Idee... Ich erzeuge aus den SQL-Tabellen-Daten eine Python-Datei. Pro Tabelle eine Datei. Die Daten sind als normale Python-Listen hinterlegt. So könnte der installer einfach die "SQL-Dump-Python-Source-Datei" importieren und hat sofort die Daten, die er einz nach dem anderen in die Tabelle ballert...


EDIT: Ich sehe gerade: Bei Moin gibt es das sog. MoinMaster wiki: http://moinmaster.wikiwikiweb.de/

EDIT2: OK Moin fällt schon mal flach, weil es die Wiki-Daten nicht in einer DB verwaltet, sondern im Dateisystem... Trac macht es sich auch einfach, da sind die default Wiki-Seiten als Dateien abgelegt. PlainText.

[jens]

Ich hab mir jetzt mal django angesehen. Dort kann man eine bestehdende Datenbank quasi importieren.
Also mit inspectdb man erhält automatisch das django ORM model der DB.

Ich bin allerdings direkt über das http://code.djangoproject.com/ticket/443 Problem gestolpert

So habe ich aber recht schnell meine model.py für PyLucid bastel können, siehe http://pylucid.net/trac/browser/branche ... py?rev=864

Ist eigentlich eine netter Automatismus, der einen viel Schreibarbeit erspart. Gibt es sowas auch in SQLAlchemy?

[apollo13]

Aufpassen inspectdb kann keine Relations (manytomany onetomany etc...) auflösen!

[Y0Gi]

In SA gibt's für Tabellen das Keyword autoload=True, wenn ich das recht in Erinnerung habe.

Weiterhin gibt es die Extension SqlSoup.