Quantcast

Rename Table limiting the down of the system

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Rename Table limiting the down of the system

Stefano T
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?
Will these operation update all the refrences in the code, such that django will keep working without problems?

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 [hidden email].
To post to this group, send email to [hidden email].
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.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rename Table limiting the down of the system

Mike Dewhirst-3
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 [hidden email]
> <mailto:[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:[hidden email]>.
> 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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rename Table limiting the down of the system

Stefano T
Thanks,
On Wed, Mar 15, 2017 at 9:43 AM, Mike Dewhirst <[hidden email]> wrote:
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'),

    ]


​the fact is that when i do renameModel it tells me that "No installed app with label.." but if run the sql statment as above it works.
in your operations there is also the alter model, why so?​

 

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

Definitely not.


​I probably asked the worng question. I was trying to infeer if references in the DB will be updated as well.​
 


--
Stefano

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAPQ1%3DkCRp5XFGzRmCUE7H1Hq%3DPD1_MAkw3kND%2BXD-m0%2BexDL-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rename Table limiting the down of the system

Mike Dewhirst-3
On 15/03/2017 8:14 PM, Stefano Tranquillini wrote:

> Thanks,
> On Wed, Mar 15, 2017 at 9:43 AM, Mike Dewhirst <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     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
>         <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'),
>
>         ]
>
>
> ​the fact is that when i do renameModel it tells me that "No installed
> app with label.." but if run the sql statment as above it works.

That is reasonable. I think the SQL is just executed as is. The
migration system permits you to run anything because it trusts you.

> in your operations there is also the alter model, why so?​

Because RenameModel only renames the model. It leaves the table
untouched. It is like you change the model name to make the design more
realistic for future maintainers of the code but assume they will never
look at the database.

Without also altering the table name in the database you would need a
meta property that says db_table=oldtablename

https://docs.djangoproject.com/en/1.8/ref/models/options/#db-table

So first rename the model name and then alter the newly named model to
match.

>
>         Will these operation update all the refrences in the code,
>         such that django will keep working without problems?
>
>
>     Definitely not.
>
>
> ​I probably asked the worng question. I was trying to infeer if
> references in the DB will be updated as well.​

I believe so, but you will have to study the source code of
AlterTableName ...

https://docs.djangoproject.com/en/1.8/_modules/django/db/migrations/operations/models/#AlterModelTable

Cheers

Mike

>
>
> --
> Stefano
> --
> 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 [hidden email]
> <mailto:[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:[hidden email]>.
> 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/CAPQ1%3DkCRp5XFGzRmCUE7H1Hq%3DPD1_MAkw3kND%2BXD-m0%2BexDL-Q%40mail.gmail.com 
> <https://groups.google.com/d/msgid/django-users/CAPQ1%3DkCRp5XFGzRmCUE7H1Hq%3DPD1_MAkw3kND%2BXD-m0%2BexDL-Q%40mail.gmail.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 [hidden email].
To post to this group, send email to [hidden email].
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/30fa6326-e8f1-d1f1-198c-33d8e9cc2b1c%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
Loading...