I agree with Markus/Tim - the whole point of faked migrations is that they're meant to exactly match the existing schema. If Django is auto-faking migrations that don't match the existing one that would be a bug, but it's almost too conservative in that aspect.
Are you manually faking these migrations? Or having Django do it for you and getting it wrong? Andrew On Wed, May 13, 2015 at 10:27 AM, Markus Holtermann < [email protected]> wrote: > Hi Steve, > > apart from what Tim said, since you commit the migration files as part > of the apps' code to your source code version control system, you can > simply have a look at the commit dates there. I'm not convinced having a > marker for faked migrations in the database is useful. > > /Markus > > > On Wed, May 13, 2015 at 10:20:15AM -0700, Tim Graham wrote: > >> I'm curious to know the reason why it would be helpful to know whether or >> not a migration was faked. When you fake a migration, you are promising >> that your schema matches the migration, so it seems to me that it would >> only matter if you made a mistake there. >> >> On Wednesday, May 13, 2015 at 12:38:38 PM UTC-4, steve byerly wrote: >> >>> >>> I couldn't find any related discussions on this topic, but I would find >>> it >>> helpful to have documentation whether a specific migration was faked or >>> not. This would allow someone to look at all migrations that have been >>> run >>> and see which ones were actually applied. >>> >>> My use case is migrating a large project to django 1.7. Since there are >>> many apps in the project the initial migrations generated are not all >>> 0001 >>> - 0002, 0003 both present. These will all get faked, but it's not obvious >>> in 6 months that migration 0003 in one app that was created as part of >>> initializing migrations was faked vs migration 0003 in another app that >>> was >>> applied. >>> >>> Adding a NullBooleanField to the model would solve the issue, but I'm not >>> positive if this is good practice. >>> >>> Thanks for the input in advance. >>> -Steve >>> >>> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/a39cbdcd-c797-4db5-89be-98cffbddf2ba%40googlegroups.com >> . >> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/20150513172703.GA5391%40pyler.local > . > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1up7B4Gqq_APVLjgXRZOB-vq0_p4WuSJ-egCJDHh8dP2aw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
