On Jun 1, 2007, at 7:22 PM, Mike Orr wrote:
> > No weak-reference error this morning, hooray. I'll be watching it for > a few days. > > Could using a BoundMetaData in my model be contributing to the > problem? I have the following structure: > i cant see how. all of that code internally uses connections from the connection pool for just one operation , then sends it right back to the pool with an explicit close(). we arent hanging on to any MySQLDB resources in any unusual way. > So when list_incidents() is called it's in a different thread than > where all the variables were defined. The engine and metadata are > thread safe, right? yes, they have no mutable state for the most part (unless you say engine.dispose() or metadata.connect()). > Should I use a DynamicMetaData and temporarily > connect it to define the tables, and then connect it to None? Or > would that just me making things more complicated for no reason? dont use DMD. not for any reason other than its needlessly complicated, yes. > As > far as I can tell there's only one engine shared throughout the > application anyway, so it shouldn't harm anything to use a > BoundMetaData. thats right. > > Could we have session.engine be an alias for session.bind_to? Pretty > please? The only reason I leave a top-level 'engine' around is in > case I need it for something, because .bind_to is so non-obvious. pylons is the reason pulling the engine off the session is even becoming popular, because it is actually using the bind_to feature, as well as that it didnt really create any easy way to get at the engine repository (not to mention the issues i raised on the pylons list). things to note about bind_to is that the session may not be bound to anything, and also can be bound to *multiple* engines in the case that someone is making it do that. which is why the "official" way to get the engine is session.get_bind(<mapper>). i dont know what im saying here other than im getting a little antsy about session / engine /etc being muddied / TMTOWTDI. theres too many choices but in this case people wanted them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
