So, it turns out that #24291 (Migrations fail with unused swappable model) <https://code.djangoproject.com/ticket/24291> only occurs when a swapped out model doesn't define an explicit model manager. Since auth.User is the only model that is officially supported for "swappiness" and it defines an explicit UserManager this isn't really a problem in my opinion. Since the whole swappable model API is internal API anyway, I don't want to rule this issue a release blocker. If projects in the wild use the swappable model API they can get around the issue by adding `objects = models.Manager()` to that model.
Tim, Russ, thoughts 'bout that? /Markus On Tuesday, February 17, 2015 at 1:05:37 AM UTC+1, Tim Graham wrote: > > Here's the status on blockers. Given the work that remains, I don't > foresee the beta release happening earlier than Wednesday, but the next > update of this thread will be tomorrow. > > #24324 <https://code.djangoproject.com/ticket/24324> Crashes when project > path or path to Django install contains a non-ascii character > <https://code.djangoproject.com/ticket/24324> > Owner: Tim > Status: Patch needs review > > > #24351 <https://code.djangoproject.com/ticket/24351> RunPython/RunSQL > operations in contrib migrations and multi-db routers. > <https://code.djangoproject.com/ticket/24351>Owner: Loic > Status: API design decision needed. Time permitting, Loic will write to > the mailing list on this tomorrow. > > #24328 <https://code.djangoproject.com/ticket/24328> The new > Options._get_fields() method needs to be cleaned up > <https://code.djangoproject.com/ticket/24328> > Owner: Anssi > Status: Anssi still reviewing the patch; decision may be needed on > backwards compatibility of get_fields(). > > #24343 <https://code.djangoproject.com/ticket/24343> UUID foreign key > accessor returns inconsistent type > <https://code.djangoproject.com/ticket/24343>Owner: Marc/Josh/Shai > Status: Josh working on cleaning up the patch. Review/feedback from Anssi > requested. > > #24291 > <https://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F24291&sa=D&sntz=1&usg=AFQjCNFRo9Jwwoq-jqakfDLb4SIzKkWJ3g> > Migrations > fail with unused swappable model > <https://code.djangoproject.com/ticket/24291> > Owner: Markus > Status: Patch looks good to me; Markus to review & commit tomorrow. > > On Monday, February 16, 2015 at 11:12:46 AM UTC-5, Tim Graham wrote: >> >> There are still quite a few unresolved issues, so the beta release won't >> happen today. I'll send an update at the end of the day with the status of >> the remaining issues. >> >> On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann wrote: >>> >>> 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://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F23271&sa=D&sntz=1&usg=AFQjCNHL39lMehjLbQRyAVQAW1lNSAPG3g>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/daee74f5-5923-4535-afa1-0e5c8f75c8a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
