I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
I do have some feedback on the @skipIfDB addition: I'd really like if this
could be used to distinguish between the different MySQL storage backends.
>From a very brief look it seems like currently there are a bunch of tests
skipped when the DB backend is MySQL, under the assumption that MySQL does
not have transaction support. However MySQL does have transaction support
when the InnoDB storage engine is used, so it would be nice if these tests
were only skipped when the MySQL/MyISAM combination were in use, not when
MySQL/InnoDB was used.
Similarly there are a bunch of tests that fail or produce errors when the
MySQL/InnoDB combination is in use, because that combination does not
support forward foreign-key references when loading fixtures. It's not ideal
to skip a bunch of tests for function that really should be tested on this
combination (aggregates, for example), but for now at least the fixtures
used by these tests do not allow them to pass on MySQL/InnoDB, so they might
as well just be skipped. I have quit ever trying to run the full Django test
suite using MySQL/InnoDB because there are just too many "known failures"
there. It would be nice if the addition of @skipIfDB improved that. (For
that matter I also never run the full suite with MySQL/MyISAM because the
lack of transaction support with that combo makes it just too slow to run
the full suite, but I don't know of any way to improve that situation.)
One difficulty in adding this extra check is that it is hard to know for
sure what storage engine is in use. If the database definition dict includes
'OPTIONS': { "init_command": "SET storage_engine=<whatever>" } then we know
the <whatever> engine is in use. If not, the default configured engine for
the MySQL server will be used, and that could be either one. I'd be inclined
to say if you want to skip tests based on a particular storage engine being
used, then you need to make it explicit in the test settings what engine you
are using. So I'd be happy if this @skipIfDB threw an error if it was asked
to skip based on storage engine but could not find in the test settings what
storage engine was being used.
Another difficulty is figuring out how to nicely specify this additional
requirement. Have not given that a whole lot of thought yet. Right now the
@skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
more than one to be listed, might get a bit ugly. I am curious why the
iterable option here was added -- are there a lot of cases in the current
suite where tests need to be skipped on a set of DB backends and not just
one?
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
