I don't know of any tickets or plans to address this.

On Wednesday, May 13, 2015 at 12:51:59 AM UTC-4, Pradeek J wrote:
>
> I'm facing the same speed issue here. Like Andrew mentioned above, if 
> initial data is going to be removed and data migrations are the way 
> forward, even having an option to skip migrations is a problem because we'd 
> need that data to be populated. Is there something planned for this for 
> Django 1.9? 
>
> On Saturday, December 27, 2014 at 8:10:10 PM UTC+5:30, Tim Graham wrote:
>>
>> In pull request 3791 <https://github.com/django/django/pull/3791>, I 
>> started working on the code removals for Django 1.9 to better understand 
>> how the database/migrations code will look and what APIs we still need to 
>> deprecate. The good news is that we can keep support for apps without 
>> migrations (at least for Django's test suite) without adding any additional 
>> code or using any deprecated database creation APIs (as Claude suggested 
>> earlier). If you look at the commit "Removed supported for syncing apps 
>> without migrations" in that PR, you'll see "Run the syncdb phase" 
>> remains in the migrate management command, but now it'll only be executed 
>> when testing (and it's also quite a bit simplified due to other removals 
>> like support for initial data). It seems like it should be pretty simple to 
>> implement something similar to the old *SOUTH_TESTS_MIGRATE* setting in 
>> order to allow disabling migrations for all apps when testing if we wanted 
>> to go that route. I think the remaining deprecations to move forward with 
>> ticket 
>> #22340 <https://code.djangoproject.com/ticket/22340> (Legacy Table 
>> Creation Methods Not Properly Deprecated) are straightforward and will 
>> leave a comment there about it.
>>
>> On Saturday, December 20, 2014 2:18:17 PM UTC-5, Aymeric Augustin wrote:
>>>
>>> There's django-admin test --keepdb for this purpose (in Django 1.8).
>>>
>>> -- 
>>> Aymeric.
>>>
>>> Le 20 déc. 2014 à 18:41, Bernard Sumption <[email protected]> a 
>>> écrit :
>>>
>>> A proposition: the problem isn't that migrations take 80 seconds, it's 
>>> that this 80 seconds is repeated every time a developer runs tests. How 
>>> about serialising the structure and content of the database to disk after 
>>> applying migrations, then whenever you need a migrated test database, load 
>>> it from disk unless the migration files have been altered since the 
>>> serialised version was created?
>>>
>>> Bernie     :o)
>>>
>>> On 20 December 2014 at 10:52, Andrew Godwin <[email protected]> wrote:
>>>>
>>>> Clause, I believe that line is to allow people to run makemigrations 
>>>> when AUTH_USER_MODEL points to an app that doesn't yet have migrations; 
>>>> before, it would fail hard, as the AUTH_USER_MODEL was not in the migrate 
>>>> state and so nothing could use it, and you couldn't run makemigrations to 
>>>> create it as it would error out.
>>>>
>>>> I'd test variations of that to see if your patch still works; if not, 
>>>> we'll need a workaround again.
>>>>
>>>> Andrew
>>>>
>>>> On Sat, Dec 20, 2014 at 10:47 AM, Claude Paroz <[email protected]> 
>>>> wrote:
>>>>>
>>>>> On Friday, December 19, 2014 6:30:32 PM UTC+1, Tim Graham wrote:
>>>>>>
>>>>>> Yes. Claude has worked on the deprecation in 
>>>>>> https://github.com/django/django/pull/3220 but it requires adding 
>>>>>> more migrations to our test suite and he noted that each migration we 
>>>>>> add 
>>>>>> to Django's test suite adds up to ~3.5 seconds to the run time of the 
>>>>>> test 
>>>>>> suite. He also worked on some speed ups to mitigate this in 
>>>>>> https://github.com/django/django/pull/3484 but there are some 
>>>>>> unsolved issues.
>>>>>>
>>>>>
>>>>> I think that the first mentioned patch I worked on (PR 3220) shows 
>>>>> that it should be possible to use the new schema infrastructure without 
>>>>> requiring migrations, at least for apps that don't depend on other 
>>>>> migrated 
>>>>> apps. Tell me if I miss anything.
>>>>>
>>>>> But surely, I'd really like to solve first the speed issue of 
>>>>> migrations (#23745, PR 3484). Chris, if you have the opportunity to test 
>>>>> that patch with your database, it would be great. The way forward for 
>>>>> this 
>>>>> patch is to first test the "if app_label == settings.AUTH_USER_MODEL 
>>>>> and ignore_swappable:" line which is currently not tested and is 
>>>>> probably not addressed by my patch. Andrew, do you remember why you 
>>>>> introduced that part of the code?
>>>>>
>>>>> Claude
>>>>>
>>>>> -- 
>>>>> 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/1f5f37b2-5309-4af6-8b3c-aa76eee3bde1%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/django-developers/1f5f37b2-5309-4af6-8b3c-aa76eee3bde1%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>  -- 
>>>> You received this message because you are subscribed to a topic in the 
>>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>>> To unsubscribe from this topic, visit 
>>>> https://groups.google.com/d/topic/django-developers/PWPj3etj3-U/unsubscribe
>>>> .
>>>> To unsubscribe from this group and all its topics, 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/CAFwN1urVDjwidnzk-%3DrEhvjYCtivcVCrtgpdserQ6B36zMdrxA%40mail.gmail.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-developers/CAFwN1urVDjwidnzk-%3DrEhvjYCtivcVCrtgpdserQ6B36zMdrxA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> 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/CALj4E%2B%2BtS%2BJ28WT51zyrqFB32zr20HU7OK4%2BiiSOdPtsky0uOg%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/CALj4E%2B%2BtS%2BJ28WT51zyrqFB32zr20HU7OK4%2BiiSOdPtsky0uOg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/f3179270-6c74-4b29-9960-5abfc7df533e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to