If anybody would like to look at a strange MySQL problem, I'd appreciate
some insights.
Checkout the queryset-refactor branch and run the null_queries test with
the 'mysql' (or 'mysql_old') backend.
`--> ./runtests.py --settings=settings1 null_queries
----------------------------------------------------------------------
File
"/home/malcolm/BleedingEdge/Django/django.git/tests/regressiontests/null_queries/models.py",
line ?, in regressiontests.null_queries.models.__test__.API_TESTS
Failed example:
Choice.objects.filter(id__exact=None)
Expected:
[]
Got:
[<Choice: Choice: Why Not? in poll Q: Why? >]
----------------------------------------------------------------------
Ran 1 test in 0.021s
FAILED (failures=1)
So the test at [1] is failing (note this is slightly different from
trunk because of ticket #2737 has been fixed/changed on the branch).
Clearly something is amiss here, since the "id" attribute is a primary
key column (not NULL and unique, by definition), so nothing should match
against the query. The generated SQL can be seen by looking at
Choices.objects.filter(id__exact=None).query.as_sql() and gives
'SELECT `null_queries_choice`.`id`, `null_queries_choice`.`poll_id`,
`null_queries_choice`.`choice` FROM `null_queries_choice` WHERE
`null_queries_choice`.`id` IS NULL'
which looks correct.
Now things get really weird: If you cut and paste the line that is
failing so you that you run it twice in a row, it fails the first time
(returning a row) and passes the second time (returning nothing)!
Normally I wouldn't worry too much about this and just chalk it up to
the high quality weed they're smoking over there at MySQL Headquarters,
but this behaviour might actually explain some questions we see from
time to time on django-users. Somebody using MySQL will update a model
and then try to query it immediately and the new value won't appear in
the query for a little bit. We've always managed to eliminate
transaction issues, so the problem was just odd. Now I have a repeatable
case (at least for values of "repeatable" that mean "on my reasonably
fast machine, every time, using MySQL 5.0.45").
If somebody else can repeat this and has the brains to work out what is
going on, that would be interesting knowledge. Does MySQL delay writing
to the database for a second or so, just for laughs? And then not take
that into account when reading? I've never seen this before, but every
time I've used MySQL in really big projects, writes and reads of the
same piece of data have been fairly widely separated.
[1]
http://code.djangoproject.com/browser/django/branches/queryset-refactor/tests/regressiontests/null_queries/models.py#L27
Thanks in advance,
Malcolm
--
Remember that you are unique. Just like everyone else.
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
