Wednesday, March 15, 2017

Re: Rename Table limiting the down of the system

On 15/03/2017 7:12 PM, Stefano Tranquillini wrote:
> Hi people.
>
> I've to do a migration for the database, specifically I've to rename a
> table.
>
> To do so I've a RunPython that runs this sql statemnet
> `ALTER TABLE "old_table" RENAME TO "new_table"`
> First question: should I use
> https://docs.djangoproject.com/en/1.8/ref/migration-operations/#renamemodel
> , does it do the same?

I believe it does the same ... certainly worked for me with Postgres.
Make an empty migration.

operations = [

migrations.RenameModel('Oldname', 'Newname'),

migrations.AlterModelTable('Newname', 'appname_newname'),

]


> Will these operation update all the refrences in the code, such that
> django will keep working without problems?

Definitely not.

The process I used was ...

1. Change the model name in your code

2. Run the dev server and fix everything which barfs. I think unit
testing creates its test database from your models rather than by
copying the database so unit tests should be fixable with
search/replace. However, any fixtures involved will undoubtedly spoil
things. ymmv.

3. Migrate and resolve any remaining issues.

Rollout to the two servers sounds like a transation nightmare to me. I
think I'd say some things are possible but expensive because you have to
set up duplicated systems for practicing such rollouts or you down the
system for a short time to make sure the data is protected.

ALSO

I have had migration squashing issues (circular references) since then.
It may or may not be the reason but I think in hindsight I would squash
all migrations prior to renaming the table.

Good luck

Mike

>
> Now, I'm using postgres and I've two servers using the same DB, let's
> call them A and B. when I'll rename the table the code will break, so
> the procedure will be:
>
> - stop A
> - update A
> - migrate
> - stop B
> - start A
>
> The problem is, that I've to be sure that migrations are atomic and
> have a transaction that locks the DB (or that table). Reading the
> documentation I found:
> /On databases that do support DDL transactions (SQLite and
> PostgreSQL), |RunPython| operations do not have any transactions
> automatically added besides the transactions created for each
> migration./ -
> https://docs.djangoproject.com/en/1.10/ref/migration-operations/ (I'm
> using 1.8)
> If i go with renameModel, will it be in a single transaction?
>
> What I want to avoid is to stop both A and B to perform migrations.
> It would be better to do the migration and then stop B, this should
> have a down that is smaller compared to stopping all services and the
> run them again.
>
> any suggestion?
>
> Ciao
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users+unsubscribe@googlegroups.com
> <mailto:django-users+unsubscribe@googlegroups.com>.
> To post to this group, send email to django-users@googlegroups.com
> <mailto:django-users@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/3205d24d-537b-4819-b2e4-e1adc31a3d46%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/3205d24d-537b-4819-b2e4-e1adc31a3d46%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9495b772-78d1-95ad-1063-4742326cb235%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment