Jonathan LaCour wrote: > This approach gives me a convenient way to manage connections and > transactions in my WSGI application at a fairly high level. In my main > HTTP dispatcher, I can essentially do this: > > > try: > start() > ... > # lookup a controller action by URL map > ... > # call the method and get the response > ... > commit() > except: > rollback() > > My controller actions don't worry about transactions or connections at > all, they just execute insert/update/delete/select actions and if an > exception is raised, their work is rolled back automatically.
well, thats exactly the pattern provided by strategy="threadlocal", and its clear that you understand how it works, so there is no problem at all doing that. its merely a pattern that allows a little less explicitness (i.e. more magic). people were quite confused by it when it was the built-in behavior, which is because a lot of people dont really understand what "threadlocal" means. so i made it all optional. no need to deprecate it though, its still useful stuff. > Can I do this without using the threadlocal strategy? What is the > pattern that you would recommend instead? well theres other ways to do it but they would be reinventions of the threadlocal strategy. > I must still not understand the appropriate usage pattern for > DynamicMetaData. I couldn't use BoundMetaData because I don't know the > connection parameters until much after import time, so I am using the > only other option I know of, which is DynamicMetaData. The fact that it > provides threadlocal behavior only caused me a headache, because I would > get errors unless it was disabled. the main use case for DynamicMetaData is a single application, usually a web application, that is actually many instances of the same application running at once and talking to different databases for each instance. so on each request, the DynamicMetaData gets pointed to the official database connection for that request, within that thread. You are free to use it the way youre using it too. if i were writing the app that didnt know the connection parameters until later, i might just put my entire "create the Tables + mappers" logic within a function call that gets called when we do know the actual connection string...but then again using DMD with threadlocal turned off is yeah a lot easier and cleaner since you can keep your declarations at the module level. its clear that you understand the libraries very well (now that you know about the "threadlocal" flag) so i dont see any issue with how youre doing things. but i would consider your patterns more advanced since they are using some tricks to allow less explicit patterns (i.e. dont need transaction instances, connections, etc). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
