I think we had this discussion, more-or-less, around South migrations (I looked a little, but couldn't find it). The context there was, as Tim hinted, "forensics" -- trying to figure out how a system came into its (broken) state. For that (as well as the OP's case, AFAICT) it makes little sense to add a flag in the migration history (really, "applied migrations") table, but it does make sense to have some sort of "migrations log", which would have a record for every migration executed (including backwards).
Shai. On Wednesday 13 May 2015 20:34:19 Andrew Godwin wrote: > 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-8 > >> 9be-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.
