--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/637c3542-c5bd-4493-8b12-44eb61f34a68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABpHFHSa4hXVrp7M2MWLcsPXSRnCnvhMQ%3D8D3q1Rg8AsAXU4Cw%40mail.gmail.com.
Some questions:
- How does the "safe" field of migrations work with other migrations related commands, such as squashmigrations? It seems to me that only migrations that share the same value of "safe" could be squashed.
- Can makemigrations figure out which migrations are "safe", such as:
- It is always safe to add a column or table.
- It is never safe to drop or rename a column or table.
If does not affect squashing. I think this is roughly reasonable, at least for my uses, although I haven't had any real world use for squash myself. I recently had to remake the migrations in my repo for $WORK project, and it made the most sense to keep them as the default safe after deploy, to match what other apps would get. I think in most cases it won't matter when the first migration is safe for practical use.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABpHFHSb2AHKb-XhZcAk6gZ3%2B%2Bt5nz7UkBUNyQ_FC%3DsYGgO_Yw%40mail.gmail.com.
How does the "safe" field of migrations work with other migrations related commands, such as squashmigrations?
You can check out our repository. We've been pretty happy with how it's working for us. https://github.com/aspiredu/django-safemigrate
there are similar to `alter table drop column` issue: `alter table rename column`, `drop table`, `rename table`. (honestly `alter table drop column` and `drop table` a bit different wiith `alter table remane column` and `rename table`)
But if you mix migrations for `alter table add column` and `alter table drop column` - you cannot safely apply both migrations simultaneously, and your proposal sounds pretty reasonable there.
However if you add disabled option, then make migration, remove field, then make migration, then apply this changes to your environment - you will get same issue. So to automate deployment process and to get achievable result you want I think you need something more complex: deploying atomic changes, but for me it sounds more about deployment than django itself.
--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/Gr9x2OlWYN4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/59bd29b1-5de3-4239-b534-fc5146995f72%40googlegroups.com.