> > 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.
I don't usually use squashmigrations either, being more likely to simply rewrite or make them initial. However, if the functionality of your module were to be added to Django itself, or become more productized, then these are the issues to think about, right? I certainly think the use case (support for something like blue/green deployments with shared database) is very important. I'm not a super experienced Django contributor, so I'd love to hear what more experienced hands have to say about it. On Mon, Jun 24, 2019 at 11:28 PM Ryan Hiebert <r...@ryanhiebert.com> wrote: > > > On Mon, Jun 24, 2019, 21:29 Dan Davis <dansm...@gmail.com> wrote: > >> >> 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. >> >> 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. > > >> - 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. >> >> This is a feature that has sounded neat to me, approximately feasible, > but hasn't yet been worth the time to implement. We've been happy adding > the safety annotations manually. > >> -- > 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-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@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 > <https://groups.google.com/d/msgid/django-developers/CABpHFHSb2AHKb-XhZcAk6gZ3%2B%2Bt5nz7UkBUNyQ_FC%3DsYGgO_Yw%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 developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/CAFzonYZpeYZGqGk3SMgYSHPk7%2BZ4vQfDNv-GaQJrjFZLivL0gQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
