On Mar 13, 2007, at 4:26 PM, Jonathan LaCour wrote:
> > Michael Bayer wrote: > >> the only change I would favor here would be to merge "connect" into >> MetaData, BoundMetaData and DynamicMetaData stay around for backwards >> compat for probably forever, and perhaps we add another method called >> "connect_threadlocal()" or something like that for people who want >> that behavior. i would like to have just one object that does the >> whole thing, now that some of the early FUD has subsided. > > To be clear: this is exactly what I want. I like the concept > of metadata I just don't like the fact that we have two objects > (BoundMetaData and DynamicMetaData) that are very different in > terms of > how you use them when they don't need to be. Putting 'connect' into > MetaData will solve my complaint nicely, and I can safely ignore the > craziness of DynamicMetaData and redundancy of BoundMetaData for the > rest of time. OK, let me tell you what just happened the other day. Im dealing with a Pylons application, and Pylons provides the SA engine by binding it to the Session. but the application also had a DynamicMetaData stuck in there, and at some point they were creating their own engine and connecting it to the DMD. needless to say I quickly got uber-confused as the app was running with *two* engines, which happened to point to the same database, but still completely weird. So i fixed it. But by changing the DynamicMetaData to just plain MetaData, i was then *sure* that no other part of the app was trying to sneak a connect() on there. Whereas if we only had one kind MetaData I could not rely upon that. Not sure if that justifies the existence of DMD since its Python, things are dynamiclaly typed, theres an endless number of operations that you cant really "guard" against. But was just a moment that I felt thankful that there *were* two versions of MetaData. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
