Modifica delle tabelle del database in Django

Question

Sto pensando di utilizzare Django per un progetto che sto iniziando (per tua informazione, un gioco basato su browser) e una delle funzionalità che mi piace di più è l'utilizzo syncdb per creare automaticamente le tabelle del database in base ai modelli Django che definisco (una funzionalità che non riesco a trovare in nessun altro framework).Stavo già pensando che fosse troppo bello per essere vero quando l'ho visto nel documentazione:

Syncdb non modificherà le tabelle esistenti

syncdb creerà solo tabelle per i modelli che non sono ancora stati installati.Non emetterà mai istruzioni ALTER TABLE per far corrispondere le modifiche apportate a una classe del modello dopo l'installazione.Le modifiche alle classi del modello e agli schemi del database spesso comportano qualche forma di ambiguità e, in questi casi, Django dovrebbe indovinare le modifiche corrette da apportare.Esiste il rischio che i dati critici vadano persi durante il processo.

Se hai apportato modifiche a un modello e desideri modificare le tabelle del database in modo che corrispondano, utilizza il comando sql per visualizzare la nuova struttura SQL e confrontala con lo schema della tabella esistente per elaborare le modifiche.

Sembra che la modifica delle tabelle esistenti dovrà essere eseguita "a mano".

Quello che vorrei sapere è il modo migliore per farlo.Mi vengono in mente due soluzioni:

• Come suggerisce la documentazione, apportare le modifiche manualmente nel DB;
• Esegui un backup del database, cancellalo, crea nuovamente le tabelle (con syncdb, poiché ora sta creando le tabelle da zero) e importa i dati di backup (questo potrebbe richiedere troppo tempo se il database è grande)

Qualche idea?

Answer 1

Come notato in altre risposte allo stesso argomento, assicurati di guardare il file Pannello di evoluzione dello schema DjangoCon 2008 su Youtube.

Inoltre, due nuovi progetti sulla mappa: Migrazioni semplici E Migratorio.

Answer 2

Entrambe le opzioni sono l'esecuzione manuale delle modifiche SQL e il dump/ricaricamento, ma potresti anche voler controllare alcuni dei pacchetti di evoluzione dello schema per Django.Le opzioni più mature sono django-evoluzione E Sud.

MODIFICARE:E ehi, ecco che arriva migrazioni.

AGGIORNAMENTO:Poiché questa risposta è stata originariamente scritta, django-evoluzione E migrazioni hanno entrambi cessato lo sviluppo attivo e Sud è diventato lo standard de facto per la migrazione dello schema in Django.Parti di South potrebbero anche essere integrate in Django entro la prossima versione o due.

AGGIORNAMENTO:Un framework di migrazione degli schemi basato su South (e scritto da Andrew Godwin, autore di South) è incluso in Django 1.7+.

Answer 3

Un buon modo per farlo è tramite i dispositivi, in particolare il initial_data infissi.

Una fixture è una raccolta di file che contengono il contenuto serializzato del database.Quindi è come avere un backup del database, ma poiché è qualcosa di cui Django è consapevole è più facile da usare e avrà ulteriori vantaggi quando si arriva a fare cose come i test unitari.

Puoi creare un dispositivo dai dati attualmente nel tuo DB utilizzando django-admin.py dumpdata.Per impostazione predefinita i dati sono in formato JSON, ma sono disponibili altre opzioni come XML.Un buon posto per riporre gli infissi è a fixtures sottodirectory delle directory dell'applicazione.

È possibile caricare un dispositivo utilizzando django-admin.py loaddata ma ancora più significativo, se il tuo dispositivo ha un nome simile initial_data.json verrà caricato automaticamente quando esegui un syncdb, risparmiandoti la fatica di importarlo tu stesso.

Un altro vantaggio è che quando corri manage.py test per eseguire i test unitari, nel database temporaneo dei test verrà caricato anche il dispositivo di dati iniziale.

Naturalmente, funzionerà quando aggiungi attributi a modelli e colonne al DB.Se elimini una colonna dal database dovrai aggiornare il tuo dispositivo per rimuovere i dati per quella colonna, il che potrebbe non essere semplice.

Funziona meglio quando si apportano molte piccole modifiche al database durante lo sviluppo.Per l'aggiornamento dei DB di produzione, spesso uno script SQL generato manualmente può funzionare meglio.

Answer 4

Sto usando django-evolution.Le avvertenze includono:

• I suoi suggerimenti automatici sono stati uniformemente marci;E
• La sua funzione di impronta digitale restituisce valori diversi per lo stesso database su piattaforme diverse.

Detto questo, trovo la consuetudine schema_evolution.py approccio a portata di mano.Per aggirare il problema delle impronte digitali, suggerisco un codice come:

BEFORE = 'fv1:-436177719' # first fingerprint
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486'

fingerprints = [
    BEFORE, AFTER,
    BEFORE64, AFTER64,
    ]

CHANGESQL = """
    /* put your SQL code to make the changes here */
    """

evolutions = [
    ((BEFORE, AFTER), CHANGESQL),
    ((BEFORE64, AFTER64), CHANGESQL)
    ]

Se avessi più impronte digitali e modifiche, lo rifattorizzerei.Fino ad allora, renderlo più pulito significherebbe rubare tempo di sviluppo a qualcos’altro.

MODIFICARE: Dato che sto comunque costruendo manualmente le mie modifiche, ci proverò migrazioni la prossima volta.

Answer 5

estensioni-comando-django è una libreria Django che fornisce alcuni comandi extra a Manage.py.Uno di questi è sqldiff, che dovrebbe darti lo sql necessario per l'aggiornamento al tuo nuovo modello.È, tuttavia, elencato come "molto sperimentale".

Answer 6

Finora nella mia azienda abbiamo utilizzato l’approccio manuale.Ciò che funziona meglio per te dipende molto dal tuo stile di sviluppo.

In genere non abbiamo così tanti cambiamenti di schema nei sistemi di produzione e implementazioni in qualche modo formalizzate dallo sviluppo ai server di produzione.Ogni volta che eseguiamo il lancio (10-20 volte l'anno) eseguiamo un riempimento differenziale del ramo di produzione attuale e di quello successivo esaminando tutto il codice e annotando cosa deve essere modificato sul server di produzione.Le modifiche richieste potrebbero essere dipendenze aggiuntive, modifiche al file delle impostazioni e modifiche al database.

Questo funziona molto bene per noi.Avere tutto automatizzato è una visione di nicchia ma troppo difficile per noi: forse potremmo gestire le migrazioni ma dovremmo comunque gestire librerie aggiuntive, server e qualunque dipendenza.

Answer 7

Django 1.7 (attualmente in sviluppo) lo è aggiungendo il supporto nativo per la migrazione dello schema con manage.py migrate E manage.py makemigrations (migrate depreca syncdb).