I've looked at the request example, but I've decided to put the MongoDB connection inside the resource instead. It's actually in the resource_factory object, and my resource objects are not recreated on every request, only when the resource tree actually changes. This is pretty similar to the way Pyramid implements the ZODB layer.
The view code (or god forbid the template code ;-) ) still has access to the connection from either request.context.db or request.root.db It has the advantage that each resource object could actually be fetching data from completely different data-store. and calling the db directly from the view code is just a development backdoor convenience. This, of course works better with traversal, but even in a url_dispatch system you still have at least one resource object. oO On Mar 14, 2:47 pm, Seth <seedifferen...@gmail.com> wrote: > Thank you everyone for your insightful comments. I would really love to see > code examples (if available) of each of these different solutions you all > are describing. I feel like I'm wading into the deep end of the pool here. > > For the record (and for those wondering), I'm using mod_wsgi (daemon mode) > for the hosting so "true" static routes aren't being handled by Pyramid, but > cycling a new dbconn for every request is still not "the right way to do it" > in my book. > > Seth -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
