#11665: django.test.TestCase should flush constraints
-----------------------------------+------------------------------------
Reporter: Glenn | Owner:
Type: Bug | Status: new
Component: Testing framework | Version: SVN
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Comment (by jsdalton):
There ended up being a lot of work in this ticket that related more to
fixing errors in the MySQL test suite than the original issue here, which
is whether and how constraint checking should be implemented during
testing.
A few things:
1. I created a new ticket (#17055) to deal with the MySQL related issues
separately.
2. While I"m still convinced of the merits of what I ultimately attempted
to do (implement constraint checks at transaction commit points to better
emulate production behavior and ensure the integrity of data in the test
databases at all times during testing), the implementation is not in a
good place for constraint checking in MySQL and SQLite. When running the
test suites today I realized that triggering constraint checks at every
transaction commit point creates unacceptable slowness in the test suite
for those backends. It runs fine on PostgreSQL however. I do not have a
good idea for how to work around it at this point in time. Also, the
constraint checking creates a variable number of SQL queries making the
suggestions for alternatives to my ignore_num_queries approach not quite
as tenable. More thinking needs to go into that.
In short, it's hard for me to see a very clear path forward for this
ticket. Checking for constraints via SQL statements is slow and there's
not a great way to work around it.
The one idea I have is we could do a "supports_fast_constraint_checks"
feature and only do the check constraints on commit if a backend had that.
The benefit here is we would catch data integrity errors before they arise
in PostgreSQL but wouldn't cause horrible slowdowns in MySQL and SQLite.
We could then also avoid the different query counts issues, or at least
apply one of those suggestions.
Anyhow, if anyone has any comments on this let me know. I'm having a hard
time motivating myself to push through a patch like that unless there's
interest.
Cheers.
--
Ticket URL: <https://code.djangoproject.com/ticket/11665#comment:41>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
