Michael,

Thank you, that explanation of the background really helps.

I have two simple questions (while the rest of what you said is still being 
digested):

On Tuesday, June 26, 2012 7:13:27 PM UTC+2, Michael Bayer wrote:
>
> However, you stated that "You might want to inherit from a class that is 
> part of production code".   Assuming this "production class" is mapped, 
> that changes everything.   When you make a subclass mapping of an existing 
> mapper, you are making not just a subclass but a new mapper() as well, and 
> you're really changing the configuration significantly, including that your 
> class is going to register itself with the base.    A subclass mapping is 
> strongly referenced by its base mapper at the moment along many paths, as 
> the mapper() is big on memoizing things so that it doesn't have to 
> recalculate expensive things more than once.  I've added 
> http://www.sqlalchemy.org/trac/ticket/2526 to think about this, but it 
> would require lots of weak references, and weak references are expensive to 
> use.
>

Without knowing the intimate details, I can appreciate the nature of the 
problem you'd have to solve there.

Isn't it also possible to "reset" the whole configuration of 
tables/mappers/metadata and other registries entirely, by clearing all of 
them out completely, and rebuilding it all from scratch?  This could happen 
both before and after a test run. 

I was thinking along the lines of metadata.clear(); clear_mappers() which 
would clear the metadata and the registry of mappers. But I am not sure how 
to clear all classes that inherit from Base, or how to reconstruct 
everything properly?

Base.metadata.create_all(bind=session.connection())   # Creating the real 
> classes (once per run)
> # there is no need to "commit" here.  SQLA DDL does this automatically.
>
>
I understood that create_all(bind=engine) would result in an automatic 
commit here, but that using create_all(bind=session.connection()) does not, 
deferring the responsibility of transaction handling to whoever is in 
control of the current transaction. Is this understanding then incorrect?

Regards
- Iwan

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sqlalchemy/-/RhFe4VTo_CIJ.
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/sqlalchemy?hl=en.

Reply via email to