Sorry all, i didn't get notified of the replies. I guess I assumed that since you are already capturing the applied migrations in the database, why not also capture if it was faked or not?
In the case I outlined in the original post, there were initial migrations (0001, 0002, 0003) and new migrations (0002, 0003). During a deploy, it's really nice to make sure you faked the right migrations/didn't fake the wrong migrations since it will not auto-fake this scenario - unless I'm missing something. I'm also unclear what the argument against storing in the migrations table is vs logging them - honest question. Since I have 4 web servers, the information would be logged to any one of them - depending on which executed the migration during deploy. On Wednesday, May 13, 2015 at 4:58:45 PM UTC-7, Markus Holtermann wrote: > > I think having the Python logging module outputting the things the > migrations framework does, seems to be a good idea. I can see some use > cases where people want to turn that on. > > I opened an issue to keep track of the feature request: > https://code.djangoproject.com/ticket/24800 > > /Markus > > On Thursday, May 14, 2015 at 1:39:02 AM UTC+2, Andrew Godwin wrote: >> >> I agree a log would be helpful, but I'm not sure that should be stored in >> the database? We could either add a history/audit table in the database or >> we could have some way of configuring a logger that stores locally (which >> is a much higher bar, but presumably where sysadmins actually want logs?) >> >> Andrew >> >> On Wed, May 13, 2015 at 2:05 PM, Shai Berger <[email protected]> wrote: >> >>> 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. >>> >> >> -- 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/9ab4ba54-8772-4a26-a11d-df0c775fbfde%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
