On Feb 26, 2012, at 12:47 PM, lars van gemerden wrote: > I was wrong, the method emptied the database, but I was checking the > tables in the metadata. > > This time I am also removing the tables from the metadata, but if i > generate the same tables in two separate test methods (with a call to > tearDown ans setUp in between), I still get an error about a backref > name on a relationship already existing.
OK I think you're mixing concepts up here, a backref is an ORM concept. The Table and Metadata objects are part of Core and know absolutely nothing about the ORM or mappings. Removing a Table from a particular MetaData has almost no effect as all the ORM mappings still point to it. In reality the MetaData.remove() method is mostly useless, except that a create_all() will no longer hit that Table, foreign key references will no longer find it, and you can replace it with a new Table object of the same name, but again nothing to do with the ORM and nothing to do with the state of that removed Table, which still points to that MetaData and will otherwise function normally. If you want to remove mappings, you can call clear_mappers(). The use case for removing individual mappers is not supported as there is no support for doing all the reverse bookkeeping of removing relationships(), backrefs, and inheritance structures, and there's really no need for such a feature. Like MetaData.remove(), there's almost no real world use case for clear_mappers() except that of the SQLAlchemy unit tests themselves, or tests of other ORM-integration layers like Elixir, which are testing the ORM itself with various kinds of mappings against the same set of classes. Unit tests in an outside world application would normally be against a schema that's an integral part of the application, and doesn't change with regards to classes. There's virtually no reason in normal applications against a fixed schema to tear down mappings and table metadata between tests. SQLAlchemy docs stress the Declarative pattern very much these days as we're really trying to get it across that the composition of class, table metadata, and mapping is best regarded as an atomic structure - it exists only as that composite, or not at all. Breaking it apart has little use unless you're testing the mechanics of the mapping itself. Throughout all of this, we are *not* talking about the tables and schema that are in the actual database. It is typical that unit tests do drop all those tables in between test suites, and recreate them for another test suite. Though I tend to favor not actually dropping / recreating and instead running the tests within a transaction that's rolled back at the end as it's much more efficient, especially on backends like Oracle, Postgresql, MSSQL where creates/drops are more expensive. Dropping and recreating the tables in the database though is independent of the structure represented by Metadata/Table, though, that structure lives on and can be reused. Metadata/Table describes only the *structure* of a particular schema. They are not linked to the actual *presence* of those tables within a target schema. -- 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.
