Das deutsche Python-Forum

Wie lösche ich in django am besten eine Tabelle?
Ich mache es ohne ORM so:

            cursor = connection.cursor()
            cursor.execute("DROP TABLE PyLucid_pagesinternal;")

Aber gilt die Syntax für alle SQL Backends?

Ich weiß wie man alle DROP statements bekommt:

Code: Alles auswählen

        from django.db import connection
        from django.db.models import get_app

        app = get_app("PyLucid")

        from django.core.management import sql
        from django.core.management.color import no_style
        statements = sql.sql_delete(app, no_style())

Aber wie bekomme ich das gezielt nur für eine Tabelle?

Ich für meinen Teil würde es nicht gut finden, dass meine Webapplikation sich eigenständig Tabellen erstellt und löscht. Da kann man leicht etwas falsch machen und dann ist die Tabelle erstmal weg.

Du kannst davon ausgehen, das niemand die Tabelle noch benötigt

Ich möchte keine unnötige Daten in der Datenbank zurück lassen.

Eines der Philosophien von PyLucid ist es, das man immer auf die nächst höheren Versionen Updaten kann. Weniger würde auch keinen Sinn machen

IMHO gehört dazu auch, das alte Daten, die nicht mehr gebraucht werden, verschwinden...

Ist dein Problem vielleicht etwas für Django Evolution? Dies scheint mir einer der fehlenden Bausteine zu sein, um zu Rails aufzuschließen (das andere wäre ein automatisches (Re)deployment a la Capistrano). Ich habe es leider selbst noch nicht ausprobiert, sieht aber sehr interessant aus.

Stefan

sma hat geschrieben:Ist dein Problem vielleicht etwas für Django Evolution?

Es gibt für Django auch dbMigration. Habe aber keines davon ausprobiert, ich mache die kleinen Änderungen immer per Hand.

Leonidas hat geschrieben:Es gibt für Django auch dbMigration.

Hatte Django-Evolution erwähnt, weil dies neulich beim "This Week in Django"-Podcast als Favorit gehandelt wurde.

Stefan

sma hat geschrieben:Hatte Django-Evolution erwähnt, weil dies neulich beim "This Week in Django"-Podcast als Favorit gehandelt wurde.

Ah, ok - das kann sein, gut zu wissen. Ich habe selten Zeit/Lust mir Podcasts anzuhören, die kann man nicht überfliegen wie normalen Text.

Der Podcast ist manchmal ein bisschen langatmig, aber ich fahre viel Bahn und da kann ich die Zeit so gut nutzen, um auf dem aktuellen Stand zu bleiben.

Stefan

Ich frage mich, wie die beiden Projekten, das bei SQLite machen. Denn ein ALTER TABLE kann bei SQLite doch fast nichts.

jens hat geschrieben:Ich frage mich, wie die beiden Projekten, das bei SQLite machen. Denn ein ALTER TABLE kann bei SQLite doch fast nichts.

Bei MySQL kann der auch vieles nicht. Ein Glück dass ich Postgres nutze, sonst hätte ich in der Vergangenheit sehr viel mehr Arbeit gehabt.

Wobei in der FAQ von Django Evolution steht:

Django Evolution is known to work well for PostgreSQL and SQLite. This is because the core developers both use PostgreSQL and SQLite on a daily basis. Support for MySQL is less complete.

Ich folgere daraus, das man mit SQLite einiges machen kann. Auf der anderen Seite steht bei den SQLite Docs das:

SQLite's version of the ALTER TABLE command allows the user to rename or add a new column to an existing table. It is not possible to remove a column from a table.

Der letzte Satz ist schon sehr einschränkend...

Ich habe immer noch eine Idee im Hinterkopf, um bei einem django Projekt die Modelle nach und nach weiterentwickeln zu können:

Wenn ich ein Modell arg ändere, dann erstelle ich eine komplett neues Model und behalte das alte erstmal bei. Somit kann ich über das ORM die Daten von dem alten Modell in das neue Model transferieren und dabei Änderungen einfließen lassen. Ist das Updaten gelaufen, kann ich mit DROP TABLE die alte Tabelle löschen. In der neusten Version des Programms, lösche ich dann auch die alte Model Klasse.

Theoretisch kann man so bei jedem Versionswechsel seine Modell umbauen und über eine Update Funktion migriert man die Daten.

Damit die Tabellen zum Model passen, könnte man mit db_table den Namen selber setzten. So könnte man die alte Model Klasse umbenennen und "_old" dran hängen, aber mit db_table auf die alte Tabelle verweisen. Die neue Model Klasse heißt dann so wie die alte, aber db_table bekommt dann z.B. eine Fortlaufende Nummer...

Naja, ich weiß nicht, ob das in der Praxis so funktioniert. Ist halt nur so eine Idee. Aber ich sollte mir mal die beiden migrations Tools von oben näher ansehen...

jens hat geschrieben:Ich folgere daraus, das man mit SQLite einiges machen kann. Auf der anderen Seite steht bei den SQLite Docs das:
SQLite's version of the ALTER TABLE command allows the user to rename or add a new column to an existing table. It is not possible to remove a column from a table.
Der letzte Satz ist schon sehr einschränkend...

Dort wird dann die Tabelle neu erstellt und die Daten kopiert.

Das deutsche Python-Forum

django und DROP TABLE...

django und DROP TABLE...