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.