django und DROP TABLE...

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 27. Februar 2008, 20:30

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

Code: Alles auswählen

            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?

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:

Mittwoch 27. Februar 2008, 20:55

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 27. Februar 2008, 21:07

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

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Samstag 1. März 2008, 12:35

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
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Samstag 1. März 2008, 15:12

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 2. März 2008, 10:41

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
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 2. März 2008, 10:54

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 2. März 2008, 11:05

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

Montag 3. März 2008, 09:43

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

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 3. März 2008, 13:52

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 3. März 2008, 14:05

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

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 3. März 2008, 17:42

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Antworten