For what it's worth, for my team, it just comes down to speed (so a single in-memory migration per app is great, and so is speeding up migrations overall).
I have a stopwatch at my desk and did some quick (unscientific) timing of creating the test DB for my own project: *Without migrations* (MIGRATION_MODULES = dict((app, '%s.fake_migrations' % app) for app in INSTALLED_APPS)) 4.94s 4.37s 5.51s 4.60s *With migrations* 80.44s 66.33s 69.09s I tried to squash migrations (52 migrations down to 7) and get timings for that, but creating test DB never completes and I don't have time to chase it down what's going on. Running tests in PyCharm's debug mode takes over 10 minutes (!!) to create the test DB, effectively eliminating our ability to use step-through debugging of unit tests. -Chris On Fri, Dec 19, 2014 at 9:30 AM, Tim Graham <timogra...@gmail.com> 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. > > On Friday, December 19, 2014 11:03:04 AM UTC-5, Andrew Godwin wrote: >> >> Hi Tim, >> >> I can have a look, but I can't be certain about hitting any deadlines. I >> do want to get that deprecation in, though... >> >> Did you want it with a view to us being able to drop that in for tests >> rather than making migrations for every test app, I presume? >> >> Andrew >> >> On Fri, Dec 19, 2014 at 3:06 PM, Tim Graham <timog...@gmail.com> wrote: >> >>> Andrew, I've thought of something similar to the in-memory migrations >>> idea you've proposed. It would be great not to have to add and maintain >>> migrations for all of the apps in Django's test suite. Do you think you >>> might be able to investigate this solution in the next month or so before >>> 1.8 alpha? I think we need a solution in 1.8 if we are to complete #22340 - >>> Legacy >>> Table Creation Methods Not Properly Deprecated (otherwise, we can again >>> postpone that deprecation). >>> >>> On Friday, December 19, 2014 8:17:05 AM UTC-5, Andrew Godwin wrote: >>>> >>>> I agree that migrations are slower than syncdb - that's perhaps the >>>> only thing worse about them - but the reason we plan to deprecate the other >>>> methods is code simplicity; migrations does not share almost any code with >>>> the old DatabaseCreation backends, and if we don't deprecate it we're going >>>> to end up maintaining two creation backends for every database driver, >>>> which isn't going to go well. >>>> >>>> There's perhaps something to be said for an option where tests make an >>>> in-memory set of migrations from the autodetector and an empty state and >>>> run them immediately - somewhat replicating the syncdb process while still >>>> using the same code paths - but I haven't had the time to investigate how >>>> well this would work yet (there are some migration decisions that would >>>> need defaults inserted). >>>> >>>> I think the end result would be an alternative test runner that you >>>> could switch to if you wanted this behaviour (and a mixin with the actual >>>> logic or something similar so it's easy to incorporate into other test >>>> runners). >>>> >>>> Andrew >>>> >>>> On Wed, Dec 17, 2014 at 6:59 PM, <c...@epantry.com> wrote: >>>> >>>>> At the risk of reviving an old topic, I wanted to add one significant >>>>> point in favor of (and mitigation for) running tests with migrations >>>>> disabled: Speed. >>>>> >>>>> Creating a test DB in sqlite for our project (~100 database tables) >>>>> takes approximately 1-2 minutes on most developer machines. 1-2 >>>>> minutes of idle time to run any test was just unacceptable so we disabled >>>>> migrations by setting fake migrations in MIGRATION_MODULES and brought the >>>>> test DB creation time down to about 5 seconds (!!). >>>>> >>>>> However the risk of committing invalid code because someone forgot to >>>>> makemigrations is real. We've addressed it by only overriding migrations >>>>> on >>>>> our local test settings and still having migrations run on our CI server. >>>>> We have our CI server use settings.test, while developers running tests on >>>>> their local machine use settings.test_local which is just: >>>>> >>>>> from settings.test import * >>>>> >>>>> MIGRATION_MODULES = ((app, '%s.fake_migrations' % app) for app in >>>>> INSTALLED_APPS) >>>>> >>>>> >>>>> This seems to get us the best of both worlds. I was surprised to read >>>>> through this thread and not see other mentions of the performance >>>>> implications of running migrations on every test run. I'd be curious to >>>>> hear if this has been a bottleneck for other teams. >>>>> >>>>> -Chris >>>>> >>>>> On Tuesday, March 25, 2014 10:21:51 AM UTC-7, Bernie Sumption wrote: >>>>> >>>>>> Hi Django devs, >>>>>> >>>>>> I've just started a new project in 1.7b, and the development >>>>>> experience working with unit tests on models is more complicated than it >>>>>> was in 1.6. It's all down to how the throwaway test databases are >>>>>> created. >>>>>> In 1.6, the create_test_db function "Creates a new test database and runs >>>>>> syncdb against it." In 1.7, it runs "migrate". >>>>>> >>>>>> While generally speaking, migrate is the new syncdb, this behaviour >>>>>> is not ideal for tests. In 1.6 "syncdb" created a database reflecting the >>>>>> current state of the models in models.py. "migrate" creates a database >>>>>> reflecting the state of the models at the last time makemigrations was >>>>>> run. >>>>>> If you're doing TDD and constantly making small changes to your models >>>>>> then >>>>>> runnning unit tests, you have to run makemigrations before each test run >>>>>> to >>>>>> get your tests to work. You therefore end up with many tiny migration >>>>>> files >>>>>> representing the minute-by-minute history of development. >>>>>> >>>>>> I came up with a pretty effective workaround that is working for me, >>>>>> but I thought I'd post this here as others are sure to encounter this >>>>>> issue, and I think that it makes more sense for the behaviour produced by >>>>>> this workaround to be the default for running tests. >>>>>> >>>>>> If makemigrations has not yet been run, the "migrate" command treats >>>>>> an app as unmigrated, and creates tables directly from the models just >>>>>> like >>>>>> syncdb did in 1.6. I defined a new settings module just for unit tests >>>>>> called "settings_test.py", which imports * from the main settings module >>>>>> and adds this line: >>>>>> >>>>>> MIGRATION_MODULES = {"myapp": "myapp.migrations_not_used_in_tests"} >>>>>> >>>>>> Then I run tests like this: >>>>>> >>>>>> DJANGO_SETTINGS_MODULE="myapp.settings_test" python manage.py test >>>>>> >>>>>> This fools migrate into thinking that the app is unmigrated, and so >>>>>> every time a test database is created it reflects the current structure >>>>>> of >>>>>> models.py. >>>>>> >>>>>> So my feature request is as follows: >>>>>> >>>>>> If the new behaviour is by design and considered desirable, then it >>>>>> is a big change from the previous version and should be prominently >>>>>> documented in the migrations and testing pages, along with the >>>>>> workaround. >>>>>> I'm happy to write this documentation if that's the way you want to go. >>>>>> >>>>>> However, if the new behaviour is not by design but just a by-product >>>>>> of the new migrations feature, I suggest making the workaround the >>>>>> default >>>>>> behaviour. I don't (yet!) know enough about Django internals to volunteer >>>>>> for this however. >>>>>> >>>>>> Thanks for your time, >>>>>> >>>>>> Bernie :o) >>>>>> >>>>>> -- >>>>> 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-develop...@googlegroups.com. >>>>> To post to this group, send email to django-d...@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/371a1e36-b752-4dad-8bc8-08c8b643e9c4% >>>>> 40googlegroups.com >>>>> <https://groups.google.com/d/msgid/django-developers/371a1e36-b752-4dad-8bc8-08c8b643e9c4%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 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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/af39502f-0e24-42bb-a661- >>> daa263836d79%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/af39502f-0e24-42bb-a661-daa263836d79%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 > 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/a9e3edb6-ed6c-48c3-99f7-1279adbec302%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/a9e3edb6-ed6c-48c3-99f7-1279adbec302%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Chris Clark │ ePantry │ 617-571-7327 1770 Union St, San Francisco, CA -- 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/CAMvP%3DCMmb2b%3DxEm4d0jnENaM-POvaz3D62_JFyyDi-5qm9LC9A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
