The easiest thing is to look how various integrations are done in the 
Pyramid scaffolds and some open source projects.

The most popular approach is to create a connection pool that is available 
to all requests; and each request will create/manage/close a connection 
as-needed.

The default implementation of sqlalchemy in the scaffolds does this by 
using a reified request property.  Touching `request.dbsession` creates the 
connection on-demand and re-uses it throughout the life of the request. 

Packages like pyramid_tm will wrap the request lifecycle in a tween, then 
issue a commit or rollback as necessary.

Without knowing much of your setup, i think you could probably do something 
like this to edit less of your code:

1. setup some factory to create a connection pool shared across requests
2. use a reified request method to grab a connection for the dbsession as 
needed.
3. either: explicitly pass the dbsession into each function on your db 
layer, or take a class-based approach where you have an instance of your 
library's object and that manages a single dbsession from the pool

There are a lot of ways to handle this though.  It sounds like you have 
so-far taken a non-standard approach.  As others chime in, you'll have to 
weigh the benefits of more standard/maintainable code vs faster development 
times.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/deecdd22-3d7a-4bef-ba31-79dcf7ae8b69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to