I just ran it on Python 2.4, 2.5, 2.6, and 2.7 with each of SQLite, MySQL, and PostgreSQL on Debian with no problems.
Thanks for the work you put into this, Russell! On Sun, Sep 26, 2010 at 6:24 PM, Karen Tracey <[email protected]> wrote: > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<django-developers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- * Chuck Harmston * [email protected] http://chuckharmston.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
