Er well the whole point of DynamicMetaData was to replace the old ProxyEngine, which was intended to emulate SQLObject's <i dont know what its called> object which is what TG was using for thread-local context.
Also, it doesnt entirely make sense that the "threadlocal" engine strategy would conflict with dynamicmetadata's thread local-ness. if you have one engine per thread, and that engine is on the tlocal strategy, it should still be doing its thing within the one thread that its used within. so feel free to try to reproduce that in a ticket or something. but also, the "threadlocal" engine strategy is the thing here thats kind of like, "you probably dont need to be using it"...its basically SA 0.1's built in behavior kind of ripped out and put over to the side, where people that really want that sort of thing can use it. but ive downplayed it a lot since then, since its kind a confusing feature if youre not the person who wrote it (or read/understood the entire source to it). whereas DynamicMetaData i think is in pretty wide usage as a thread local construct and its pretty straightfoward. the non-threadlocal use case for it is not as obvious to me. On Mar 12, 2007, at 4:58 PM, Jonathan LaCour wrote: > > Random question for the list, and an idea. I have an application I am > working on that needs to be able to dynamically bind its metadata to > an engine based upon configuration. Logically, it seems I should use > `DynamicMetaData` and just call metadata.connect(engine) after I have > loaded my configuration. > > However, I had written all of my code depending upon a threadlocal > strategy as defined by using `strategy='threadlocal'` in my > `create_engine` call. It turns out that DynamicMetaData has > threadlocal > behavior by default as well, and somehow these two things > conflict. My > problem was solved by making sure to pass `threadlocal=False` to my > DynamicMetaData constructor. > > Now, here is my question: why does DynamicMetaData have any > threadlocal > behavior at all? It seems like the primary reason one would use a > DynamicMetaData would be for being able to delay the binding of your > engine to your metadata. The fact that its threadlocal is easy to > miss, > and I don't see why it has any threadlocal behavior at all. > > Am I missing something? Wouldn't it be better to two separate > MetaData > types, one for dynamically binding your engine, and another for > threadlocal metadata? > > -- > Jonathan LaCour > http://cleverdevil.org > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
