#8138: Switch django tests to use transactions
----------------------------------------+-----------------------------------
Reporter: mremolt | Owner: nobody
Status: new | Milestone: post-1.0
Component: Testing framework | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------
Comment (by ramiro):
Replying to [comment:18 kmtracey]:
> Third and one I haven't entirely figured out is this failure, only with
PostgreSQL, in the fixtures test:
>
> ...
>
> The difference is in the times, they are an hour off. Luke also
mentioned seeing this on the mailing list, only his times were off by 6
hours. I'd guess Luke's real time zone was 6 hours off from
'America/Chicago' while I am 1 hour off from 'American/Chicago'. I can
make this failure go away by setting the TIME_ZONE setting to match my
real time zone, but I haven't figured out why this is necessary only when
using the rollback approach -- how did the times workout properly without
a TIME_ZONE setting in the flush/reload approach?
I've been trying to wrap my head about what could be the cause of this. In
my case I'm currently four hours ahead of Chicago, but back in June 2006
(the times used in the Article objects contained in the fixtures) we were
just two hours ahead and that's the time difference I was seeing in the
test error.
I checked that the `TIME_ZONE` setting value was efectively being sent
with `SET TIME ZONE` to the DB in postgresql_psycopg2's ªDatabaseWrapper
`_cursor` method when the `syncdb` and `loaddata` managemente commands
were being called inthe same doctest.
All this seemed to confirm that for some reason, when `dumpdata` was being
called the data it was getting from the DB was being converted to the
local time zone. Then when I saw the call to `set_isolation_level(1)` in
`_cursor` method it occurred to me that what could be happening is that
the rollback operations used in the new approach were undoing even the
`SET TIME ZONE` clause effects. Adding a `commit()` call right below it
solved the problem. I don't know if it's a correct fix and if it's the
right place where this should be fixed (becaus I don't know if does
adversely affect normal usage and the flush/recreate approach) but I hope
it is of some help.
{{{
diff -r e40efae5e6f9 django/db/backends/postgresql_psycopg2/base.py
--- a/django/db/backends/postgresql_psycopg2/base.py Sat Jan 03
15:06:38 2009 -0200
+++ b/django/db/backends/postgresql_psycopg2/base.py Sat Jan 03
23:29:17 2009 -0200
@@ -88,6 +88,7 @@
cursor.tzinfo_factory = None
if set_tz:
cursor.execute("SET TIME ZONE %s", [settings.TIME_ZONE])
+ self.connection.commit()
if not hasattr(self, '_version'):
self.__class__._version = get_version(cursor)
if self._version < (8, 0):
}}}
--
Ticket URL: <http://code.djangoproject.com/ticket/8138#comment:21>
Django <http://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
-~----------~----~----~----~------~----~------~--~---
