Hello. > OK, that's unusual but that is actually the case where clear_mappers() is fine to use. SQLAlchemy's own unit tests create new classes for each test because we're testing SQLAlchemy itself.
> OK, yes this is correct, as the compilation step tries to get at all mappers. Sorry I didn't realize this, it's very strange for end-user unit tests to be testing the creation of ad-hoc mapper configurations. Thank you for your clarification. At this time I still play with/learn SQLAlchemy and unit tests are the fastest way to learn it, at least for me. I don't want to write new module file with a single test case to play with, hence I define ORM classes locally in each test and test my assumptions about how SQLAlchemy works :-) Ladislav Lenart On 18.9.2012 17:40, Michael Bayer wrote: > > On Sep 18, 2012, at 11:36 AM, Ladislav Lenart wrote: > >> Hello. >> >> Adding call to clear_mappers() to tearDown fixed my problem. >> >> For the rest of the discussion I am not sure I completely follow. >> >> I use declarative exclusively but each test defines its own Base and its own >> set >> of ORM classes. > > > OK, that's unusual but that is actually the case where clear_mappers() is > fine to use. SQLAlchemy's own unit tests create new classes for each test > because we're testing SQLAlchemy itself. > >> However when one test has a bug in an ORM class definition, ALL >> the following tests fail because of this. > > OK, yes this is correct, as the compilation step tries to get at all mappers. > Sorry I didn't realize this, it's very strange for end-user unit tests to be > testing the creation of ad-hoc mapper configurations. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
