On Thu, Feb 6, 2014 at 5:13 PM, Michael Bayer <mike...@zzzcomputing.com> wrote: > > you can use a per-connection cache using connection.info, and you can also > manage the lifecycle of the connection and the cache of items with connection > and/or pool events as well (e.g. if connection.rollback() clears out prepared > statements). lots of functions already do things like this, like keeping > track of XA handles and such. it wouldn't really be hard at all actually, as > long as the DBAPI itself behaves nicely when lots of handles are allocated.
I don't think the DBAPI cares, but the backend might. I know complex query plans can sometimes take several MB to cache, so if you had many of those, the cost in memory could be important. But, since this has to be explicitly enabled, I don't think it should be a matter. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
