Hey folks, I looked into the issues #24225, #24264 and #24282 and have a working pull request ready for review: https://github.com/django/django/pull/4097
The essential change in the pull request is the way how the set of models that needs to be rerendered is constructed. Instead of naively only resolving one level of relations (Only rerender B and C if C changed: A --> B --> C) the new approach recursively checks for relational fields (forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as well as inheritance. This approach boils down to the following behavior: If a completely standalone model (no incoming or outgoing relations and no subclasses and only a directed subclass of models.Model) changes, only this model will be rerendered, which is the best case scenario. If every model is somehow related (directly or through other models) to every other model, e.g. through the user model, changing one model from that set will require *all* models to be rerendered, which is the worst case scenario and results in the similar behavior as 1.7. To get that pull request into the 1.8 beta I ask everybody to take a look and try it out on their projects. Especially if 1.8 alpha 1 didn't work for you. Thanks /Markus On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote: > > As we approach the date for 1.8 alpha, I plan to send a weekly update on > the status of release blocking issues. > > We currently have 3 release blockers affecting master. You can use this > Trac filter to see them: > > https://code.djangoproject.com/query?status=assigned&status=new&version=master&severity=Release+blocker > > You can also see other tickets we are targeting for 1.8 with this filter. > This includes some of the remaining large features as well as a couple code > reorganizations we want to make closer to when cut the 1.8 branch to avoid > creating conflicts with the large features that are in progress. > > https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha > > Here is a summary of where we stand with each release blocker: > > #23861 - > <https://code.djangoproject.com/ticket/23861> Fields referenced in > migrations cannot be (re)moved, even if migrations have been squashed > <https://code.djangoproject.com/ticket/23861> Owner: ? > Status: We need someone to investigate a strategy for how we can deprecate > model fields while keeping them available in historical migrations. Any > takers? If we cannot complete this, I propose we bump the deprecation of > IPAddressField until the issue is solved. > > #22340 - > <https://code.djangoproject.com/ticket/22340> Legacy Table Creation > Methods Not Properly Deprecated > <https://code.djangoproject.com/ticket/22340> Owner: Claude > Status: This issue is being discussed in the thread "Migrations in Django > 1.7 make unit testing models harder". In short, we likely to need to solve > the performance issues with migrations before we can proceed with the > deprecation. If we cannot, we'll likely have to delay the deprecation. > > #23271 - <https://code.djangoproject.com/ticket/23271>Makemessages can > corrupt existing .po files on Windows > <https://code.djangoproject.com/ticket/23271> > Owner: Ramiro > Status: Ramiro said he would have some time to investigate the issue soon. > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/347cdd1d-bb4e-406e-bc85-f75f9c99ead5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
