#11665: django.test.TestCase should flush constraints
------------------------------------+-----------------------------------
Reporter: Glenn | Owner:
Type: Bug | Status: new
Milestone: | 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):
Pasting a conversation between myself and jacobkm on IRC:
[4:50pm] jacobkm: jsdalton: what's connections._ignore_num_queries for?
[4:50pm] • jacobkm smells a hack
[4:50pm] jsdalton: jacobkm: lol. the problem is that MySQL uses a
different number of queries to perform certain operations, basically it's
inconsistent
[4:51pm] jsdalton: mostly this had to do with fixture loading, if i recall
correctly
[4:51pm] dgovinda left the chat room. (Ping timeout: 276 seconds)
[4:51pm] dgovinda joined the chat room.
[4:51pm] jsdalton: to be honest, expecting a consistent query count across
multiple backends with differing implementations sort of struck me as
problematic
[4:52pm] jacobkm: jsdalton: so it's a workaround to make assertNumQueriese
consistent across backends?
[4:52pm] jacobkm: jsdalton: I'd rather see something more like "if backend
== mysql: assertNumQuerys(6)" sort of thing.
[4:52pm] jsdalton: hm
[4:52pm] jacobkm: This seems... evil and undocumented.
[4:52pm] jsdalton: hm, thinking
[4:53pm] jacobkm: IOW I'd rather work around it in the tests than have it
all up in django.db.
[4:54pm] jacobkm: jsdalton: other than that I think this looks really
good. We'll need to put something in the release notes -- this has
potential backwards-compatibility implications -- but if you've not got
time I can take care of that.
[4:55pm] jsdalton: jacobkm: cool, sorry just opening up my code here and
reuploading my thought process to my brain
[4:55pm] jacobkm: jsdalton: no worries!
[4:56pm] jacobkm: jsdalton: I'm headed for lucnch but I'll check in when I
get back so leave anything here for me if you like.
[4:56pm] jsdalton: sounds good i'll see if i can recall my train of
thought by then
[5:00pm] jsdalton: jacobkm: for when you return, here's a very brief
summary of my reasoning behind ignore_num_queries for you to consider
[5:02pm] jsdalton: first, the reason for is the implementation of
check_constraints() varies across backends (i believe MySQL and SQLite are
different from the others)
[5:03pm] jsdalton: so yeah one solution would be to set up different
assertions for each backend in those tests where they were inconsistent.
that was probably what i wanted to do but i felt like that was cheating,
since that could conceivably be prone to breakage down the road as
implementation details changed
[5:03pm] jsdalton: be that as it may, i'd probably be fine with that
[5:05pm] jsdalton: i implemented ignore_num_queries because it seemed like
a better more flexible long term solution. i did add tests for it as well,
btw.
[5:05pm] jsdalton: if you look closely at the implementation, it doesn't
*really* touch production code
[5:06pm] jsdalton: it adds a single private attribute to the connections
variable in django.db
[5:07pm] jsdalton: otherwise, the only other place it lives is in
CursorDebugWrapper, i.e. the same place where num queries does its thing
[5:09pm] jsdalton: and for now it's only used in the test suite around a
piece of test code that emulates constraint checking
[5:10pm] jsdalton: anyhow, not sure this is a very strong case for it. to
me it felt like less of a hack because it's just a way of telling assert
num queries to ignore query counts for certain blocks of code, but if my
argument is not particularly convincing i can take your suggestion of
specifying different query counts per backend
If we can get a decision on @ignore_num_queries as a decorator vs.
specifying different expected query counts per backend, I'd be happy to
implement either and proceed. Jacob also mentioned documentation in the
release notes, which I can try to tackle as well.
--
Ticket URL: <https://code.djangoproject.com/ticket/11665#comment:38>
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.
