On Wednesday, March 1, 2017 at 2:09:06 PM UTC+1, Larry....@gmail.com wrote:
I had thought of using a view, but that would have been a lot of
overhead on such a large table. I also considered adding a column and
running a one time script to update the existing rows, and modifying
the script that loads data to populate the new column. But doing an
alter on such a large table takes longer then we can afford to have
the table locked for.
It depends on your needs, of course. Your solution described earlier is widely adopted.
Also, we don't use django migrations on this project. We have found
them very hard to manage in an environment where you have 40
deployments, all with different versions of the code and database.
Good decision. There are many other factors like unavailability of migrations after application's code changes (due to "freezing" class references).
BR,
Marcin
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/d1bfae54-202c-4c9f-9665-200292396642%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment