Migrazione nuovo database oppure dump+restore?

[pastrufazio]

Ciao a tutti,

facendo delle prove ho visto che creare un database vuoto in PostgrSQL e poi popolarlo col dump di un altro database mi risparmia di dover fare la solita procedura makemigration+migrate.

/usr/bin/pg_dump -Ft --no-acl --no-owner -h <HOST> -p 5432 -U <USER> <DB_DA_COPIARE> -f /tmp/dump.tar  && \
/usr/bin/pg_restore -n public -h <HOST> -p 5432 -U <USER> -d <DB_NUOVO> /tmp/tmp.tar

Per ora non ho avuto alcun problema, ma vi chiedo: ci sono controindicazioni a procedere in questo modo?

Sto trasformando il nostro applicativo back-end in multi-tenant e per questo devo replicare i database tali e quali (per poi ripulire in ciascuno i dati non pertinenti al tenant).

Grazie a tutti.

[Karim]

On Wed, Jan 30, 2019 at 2:39 AM pastrufazio <pastr...@gmail.com> wrote:

...

Per ora non ho avuto alcun problema, ma vi chiedo: ci sono controindicazioni a procedere in questo modo?

Non ho ben idea di cosa stai facendo con il multi-tenant, ma il dump e restore e' una cosa che faccio continuamente in develop per testare i miei vari branch o fare revert. E' una prassi abbastanza comune.

Ciao

 

--

Karim N. Gorjux

[pastrufazio]

Il giorno mercoledì 30 gennaio 2019 09:21:30 UTC+1, Karim ha scritto:

On Wed, Jan 30, 2019 at 2:39 AM pastrufazio <pastr...@gmail.com> wrote:

...

Per ora non ho avuto alcun problema, ma vi chiedo: ci sono controindicazioni a procedere in questo modo?

Non ho ben idea di cosa stai facendo con il multi-tenant,

Mi spiego meglio: l'applicativo di back-end che ho ereditato al momento serve più webapp con un unico database. Sto cercando di predisporre un database per webapp, in modo da gestire più facilmente eventuali customizzazioni e semplificare le chiamate al back-end.

Per fornire alle webapp già esistenti un proprio database isolato, quindi, mi copio il database con la procedura descritta sopra e poi lo ripulisco lasciando dai dati delle altre webapp.

Per quanto riguarda il codice, sto seguendo questa guida, che mi pare davvero ben fatta

http://books.agiliq.com/projects/django-multi-tenant/en/latest/index.html

 

ma il dump e restore e' una cosa che faccio continuamente in develop per testare i miei vari branch o fare revert. E' una prassi abbastanza comune.

Ottimo, grazie! quindi se non ho capito male anche tu per far il revert non vai di

python manage.py migrate nome_app 000X_stato_da_ripristinare

ma procedi direttamente col restore del dump di database che ti interessa? anche perché nel database è presente  lo storico delle migrazioni (migrate), quello cioè che viene mostrato da 

python manage.py showmigrations nome_app

e quindi proprio per questo col restore del dump abbiamo risolto. Ti torna tutto? perdona l'insistenza ma non ho grande esperienza e prima di muovermi voglio essere sicuro.

Grazie ancora.

 

[Karim]

On Wed, Jan 30, 2019 at 10:03 PM pastrufazio <pastr...@gmail.com> wrote:

[...]

Mi spiego meglio: l'applicativo di back-end [...]

Non conoscevo la multi-teenant su piu' database. Mi sembra qualcosa di laborioso, ma se i requisiti lo richiedono, si fa. :-)

 

Tornando a noi.

[...]

Ottimo, grazie! quindi se non ho capito male anche tu per far il revert non vai di

python manage.py migrate nome_app 000X_stato_da_ripristinare

ma procedi direttamente col restore del dump di database che ti interessa? anche perché nel database è presente  lo storico delle migrazioni (migrate), quello cioè che viene mostrato da 

python manage.py showmigrations nome_app

e quindi proprio per questo col restore del dump abbiamo risolto. Ti torna tutto? perdona l'insistenza ma non ho grande esperienza e prima di muovermi voglio essere sicuro.

Esatto. Io generalmente uso il db di QA come snasphot di base perche', in fin dei conti, io brancho da develop quando sviluppo.

Faccio tutte le cose che devo fare nel mio branch e poi faccio le migrations. A volte mi capita di dover passare ad altro branch e a quel punto restoro il dump di QA.

Una cosa che faccio sempre e' quella di non commitare mai le migrations del mio branch se non all'ultimo commit quando sono pronto per mergiare in develop.

Quindi, prima di mergiare in develop, genero le migrations e le committo. Tieni presente che se scrivi test, non hai bisogno di creare migrations.

Ovvio, il caso di migration che fanno migrazione di dati con funzioni custom, e' diverso.

Ciao

 

--

Karim N. Gorjux