lazy initialization to support per-thread engine proxy

[sqlalchemy-bot]

lazy initialization to support per-thread engine proxy

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

OK, well at first I was thinking, "you dont have to do that...." but yes, since a class is a global declaration, which points to its mapper, which points to tables, the same table would have to talk to different DBs per "request". I would say right off that building such an app, i.e. one that context-switches all over the place, is generally a huge pain in the ass and takes away from one of the original reasons people like Python, that its easy! Also I was surprised that Paste has this requirement, but it rings a bell, but I would guess that nothing is seriously going to make usage of it....its just too easy to start separate servers for different applications or use something like mod_python which has PythonInterpPerXXXX functionality....also would perform better.

But yes the need will exist regardless. But, I think this need is going to be an exception case, so that if an application is not using the proxy engine, it should not have to pay any price. Placing the burden on "context-switching" and "caching" of attributes within the Table implies that the ProxyEngine doesnt worry about it, and also that anything else which wants to hold onto ProxyEngine values has to worry about the same thing. Additionally, its code overhead on a per-attribute-access, no matter what engine is being used.

So why not have ProxyEngine do more of the work, and have it return proxying versions of TypeEngine, TableImpl, ColumnImpl, and whatever else as well ? That way ProxyEngine can define some high-performing and cache-aware scheme to quickly return thread-local/context-local attributes in only one place, instead of sprinkled about Table and whatever else in the sql.* package that might need it, and no external code has to worry about it. if ProxyEngine is not used, as I think will be more common, then the additional per-attribute overhead is gone. It also means if you do something like repr(table), or table.c.col1.type == table2.c.col2.type, it will work consistently since its the same object instances being returned.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

new proxy engine merged in changeset:884. thanks jason !

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• changed status to closed