Qual è la differenza tra la creazione di tabelle DB utilizzando alembic e la definizione di modelli in SQLAlchemy?

Question

È possibile creare tabelle utilizzando il comando alembic revision -m 'table_name' e quindi definire le versioni e migrare utilizzando alembic upgrade head.

Inoltre, è possibile creare tabelle in un database definendo una classe in models.py (SQLAlchemy).

Qual è la differenza tra i due? Sono molto confuso. Ho incasinato il concetto?

Inoltre, quando eseguo la migrazione del database utilizzando Alembic, perché non forma una nuova classe nel mio models.py? So che le tabelle sono state create perché li ho controllati utilizzando un browser SQLite.

Ho già eseguito tutte le configurazioni. L'obiettivo per il database di Alembic e SQLALCHEMY_DATABASE-URI in config.py è lo stesso file .db.

Answer 1

Sì, ci stai pensando nel modo sbagliato.

Supponiamo che tu non usi Alembic o qualsiasi altro framework di migrazione. In questo caso si crea un nuovo database per l'applicazione con le seguenti operazioni:

1. Scrivi la classi del modello
2. creare e configurare un nuovo database di zecca
3. Run db.create_all(), che esamina i vostri modelli e crea la tabelle corrispondenti nel tuo database.

Quindi ora considerare il caso di un aggiornamento. Ad esempio, supponiamo che tu rilasci la versione 1.0 della tua applicazione e ora inizi a lavorare sulla versione 2.0, che richiede alcune modifiche al tuo database. Come puoi ottenerlo? La limitazione qui è che db.create_all() non modifica le tabelle, può solo crearle da zero. Così va la vita in questo modo:

4. Apportare le modifiche necessarie alle classi del modello

5. Ora avete due opzioni per trasferire le modifiche al database:

   5.1 Destroy il database in modo che è possibile eseguire nuovamente db.create_all() per ottenere le tabelle aggiornate, magari il backup e il ripristino dei dati in modo da non perderlo. Sfortunatamente SQLAlchemy non aiuta con i dati, dovrai usare strumenti di database per questo.

   5.2 Applicare le modifiche manualmente, direttamente al database. Questo è soggetto a errori e sarebbe noioso se il set di modifiche è grande.

Ora considera di avere database di sviluppo e produzione, il che significa che il lavoro deve essere eseguito due volte. Pensa anche a quanto sarebbe noioso quando hai diverse versioni della tua applicazione, ognuna con uno schema di database diverso e devi indagare su un bug in una delle versioni precedenti, per cui è necessario ricreare il database come era in quello pubblicazione.

Vedere qual è il problema quando non si dispone di una rete di migrazione?

Utilizzando Alembic, si ha un po 'di lavoro extra quando si avvia, ma si paga perché semplifica il flusso di lavoro per gli aggiornamenti.La fase di creazione va come questa:

1. Scrivi la classi del modello
2. creare e configurare un nuovo database di
3. Generare un migrazione iniziale Alembic, sia manualmente che automaticamente. Se vai con le migrazioni automatiche, Alembic guarda i tuoi modelli e genera il codice che li applica al database.
4. Eseguire il comando upgrade, che esegue lo script di migrazione, creando effettivamente le tabelle nel database.

Poi, quando si raggiunge il punto di fare un aggiornamento, effettuare le seguenti operazioni:

5. Apportare le modifiche necessarie alle classi del modello
6. Generare un'altra migrazione Alembic . Se lasci che Alembic generi questo per te, confronta le tue classi di modelli con lo schema corrente nel tuo database e genera il codice necessario per fare in modo che il database corrisponda ai modelli.
7. Eseguire il comando upgrade. Questo applica le modifiche al database, senza la necessità di distruggere alcuna tabella o eseguire il backup dei dati. È possibile eseguire questo aggiornamento su tutti i database (produzione, sviluppo, ecc.).

cose importanti da considerare quando si utilizza Alembic:

• Gli script di migrazione diventano parte del codice sorgente, quindi hanno bisogno di essere impegnati a controllo del codice sorgente con i propri file.
• Se si utilizza la generazione di migrazione automatica, è sempre necessario rivedere le migrazioni generate. Alambicco non è sempre in grado di determinare i cambiamenti esatti, quindi è possibile che lo script generato abbia bisogno di una regolazione fine manuale.
• Gli script di migrazione hanno le funzioni upgrade e downgrade. Ciò significa che non solo semplificano gli aggiornamenti, ma anche i downgrade. Se hai bisogno di sincronizzare il database con una vecchia versione, il comando downgrade lo fa per te senza alcun lavoro aggiuntivo da parte tua!

Answer 2

posso aggiungere che per Django ci sono due comandi

makemigrations (which creates migrations files) 
migrate (which translates migrations into sql and executes them on database) 

Ho trovato la sua grande per la comprensione di qualcuno per passare tra le batterie quadro incluso (Django) e di altri framework come Flask/Falcon.

Pertanto, l'utilizzo delle migrazioni alambicco è molto comodo e semplifica il monitoraggio delle modifiche del database.