On 3/14/07, JP <[EMAIL PROTECTED]> wrote: > > On Mar 13, 11:59 am, "Gaetan de Menten" <[EMAIL PROTECTED]> wrote: > > 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? > > Not me -- I have cases where the same schema is used with two > different databases by two different apps (eg, admin uses a main > postgres db and public uses a local sqlite cache), so the current API > does what I need, but (if I understand what you're saying) only > allowing the connect string of a global engine to vary per request, > rather than allowing completely different engines, would not.
Yeah, I figured in the meantime that this case could cause problem. The point I have is that this case is _in my opinion_ much less common than the case where you need to delay the setup of your tables and use the DynamicMetaData for that. So I think it would have been better to have a DynamicMetaData with threadlocal=False by default. If that were the case, people would not have to connect the metadata to the engine in each and every thread. Now it's too late if we don't want to break backward compatibility but simply adding a connect method to the "standard" MetaData, as Michael proposed, would suit my needs just fine. Anyway, I've already rambled too much on this issue... Thanks for having taken the time to answer my question. -- 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 -~----------~----~----~----~------~----~------~--~---
