The request is for anything you need. Some frameworks pass a request and response to the view and have other global objects and things, but Pyramid tends to use the request to put all that stuff in one place. Even semi-exceptions like 'context' that can be received separately are also in the request. So I would do likewise, starting with database connections.
In one application I have SQLAlchemy sessions to three databases, the underlying engines to them, a Redis connection pool, an ldap3 pool, things from tweens, and maybe other things. I tried different strategies like add_request_method, a request subclass, and pyramid_services. I ended up using a request subclass just because it was easier to manage all those things together rather than piecemeal, If I had only one or two I'd use add_request_method. And I use reify as much as feasable. Global things used across all requests can go into 'registry' or 'registry.settings', or you can use pyramid_services or the registry interface API. Things like engines and connection pools are global and thread-save so you can use them directly, although I ultimately found it more convenient to make reified request properties that shadow them. SQLAlchemy sessions have to be created for each request, so I use reified properties for those, getting the engine from the registry. The features example you cited has an object that knows about the features. But aren't boolean features ultimiately controlled by configuration settings to enable them? You may be able to just use the settings, or define your own settings, and then you wouldn't have to make custom request properties. On Fri, Jan 29, 2016 at 4:35 AM, Torsten Irländer <tors...@irlaender.de> wrote: > Hi all, > > The request is available almost everywhere is a pyramid application. This > makes it seductive to use the request to pack many more properties to the > request und (mis?)use it as a carrier for some kind of "dependency > injection". > > I already added the current DB connection (which seems to be a widley used > pattern) to it, and some other small thing. But I am wondering how the > request is meant to be used. Is it OK to use the request for such things? I > tend to say that adding more and more properties to the request (even if > they are related to the request) is some kind of misuse and not intended by > the developers. > > What do you think? > > For those who are interested in some background of this question: This > questions arised when talking about how to implement Feature Toggles. See > https://github.com/ringo-framework/ringo/issues/6 > > best regards, > Torsten > > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pylons-devel+unsubscr...@googlegroups.com. > To post to this group, send email to pylons-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/pylons-devel. > For more options, visit https://groups.google.com/d/optout. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
