On 7 syys, 01:21, Anssi Kääriäinen <[email protected]> wrote: > On 7 syys, 00:35, Andrew Godwin <[email protected]> wrote: > > > That's an incredible speedup - I've had a quick look over the patch, and it > > looks to be doing all the right things, so I'd definitely be behind merging > > this in. Have you tried running the test runner over some third-party apps' > > tests to make sure it works? I suspect South's/migrations' might get weird, > > but then I do nasty things and that's my problem to fix. > > I haven't ran any tests except the Django's test suite. How things > should work is that if you use full_flush everything works as always, > and if you don't then the only problem should be raw SQL queries (or > in South's case probably also queries done through the migrations > ORM). If things actually work that way is still an open question :) > > For raw SQL queries and other changes which aren't done through > Django's ORM you can use either self.changed_models.add(some_model) or > django.db.models.signals.model_changed.send(some_model) to mark that > model's table as dirty. > > Testing this on real world apps would be really useful!
Actually, if there are triggers or cascading foreign keys in the DB, then changes made by those will of course not be noticed by state tracking. Seems like a documentation issue to me. Also, I think I will need to improve the "detect state leaks" code, if we have that more robust, then it should be fairly trivial to spot if there are any state leakage problems in the tests. The only commit needed for state tracking to work is the https://github.com/akaariai/django/commit/fdff4957a5226465b32b6f82bb81fdd37543f440 one. The other commits do some further optimizations, and should be reviewed & applied separately (although the permission creation commits will not apply cleanly to master). The further optimizations are only important to make SQLite testing as fast as possible on Django's test suite. I did a comparison of how much an average TransactionTestCase takes on PostgreSQL when running the full test suite. On master: 8-9s, on all optimizations branch: 0.1s (with some tests taking a lot longer if they dirtied a lot of data). So, there is nearly two orders of magnitude speedup. In real-world apps the speedup isn't likely that big, as we do have an unusual amount of models in the tests. On the other hand, if you like Selenium tests, you are going to have a lot of TransactionTestCases. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
