I only discovered (or at least understood) this thread localness of DynamicMetaData, and honestly, I don't understand in what case it can be useful. It seems like the thread localness is limited to the engine connected to the metadata. So what I'd like to understand is when anyone wouldn't want to use a global engine? As long as the connections are thread-local, we are fine, right?
On 3/12/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > 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 > > > > -- Gaëtan de Menten http://openhex.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 -~----------~----~----~----~------~----~------~--~---
