BTW, pyramid is pretty much designed so that you can eliminate all magic globals and thread locals by keeping a locally passed reference to request everywhere. I'm curious where you are finding it not accessible? For us, we pass it into formencode validators as part of the state variable, it's already in the root factories, available to templates, and in any views. Where else do you have code that needs the registry? ( curious, not saying you've necessarily done something wrong )
thanks Iain On Thu, Dec 1, 2011 at 9:28 AM, Iain Duncan <[email protected]>wrote: > Hi Vlad, I'd recommend taking a look at your architecture and figure out > why request is not available and whether you can fix that. We've > (re)designed our system so request is *always* available, as well as > tightly controlled ( custom request factory to build it, and end of life > callback to close it down ) and it makes everything much much easier to > trace and to test. So for example, our db layer is wrapped up an > AbstractModel class, no db calls happen except through that object, and it > gets instantiated at the beginning in the request factory, and cleaned up > at the end by the request finished callback. Any code, anywhere knows to > get persistence data through request.model, which is guaranteed to be local > only to that thread. The only registry access outside of request > availability is in the app start up where we use it alongside the > configurator. We've followed the same thing for other components too. > > Just a though, as I used to have registry calls happening elsewhere, but > have saved lots of pain but tying it all to the request lifecycle now. > > hth > iain > > On Thu, Dec 1, 2011 at 9:17 AM, Vlad K. <[email protected]> wrote: > >> >> Excellent suggestions, thanks! >> >> The globals are not my cup of tea so my feet are currently safe from that >> Django pattern. :) I do care about testing and have written unit tests >> (although the code I need this in is currently not covered by the tests), >> but just to understand the issue at hand, what can go wrong if I only read >> the setting like in your get_setting def example? >> >> I know about thread safety and writing shared data, and I know from C >> that even reading data which is in the middle of a write by another thread >> can produce corrupt results (especially with nonatomic data types). Is that >> the case even in Python? The settings I need to read are some custom config >> values that never change in the life of the application (and I say this >> fully aware of the fact that almost everything in Python is a reference, >> especially when dealing with lists and dictionaries which can be changed >> "accidentally"). >> >> Basically my problem is only that of the separation of concerns. I have a >> database model that logs certain operational stuff (not python logger) and >> I want it to mail the error entries to the admin, so I want it "agnostic" >> to the request chain and views used, because it can be called in views, or >> command line scripts (using pyramid.paster.bootstrap), etc... It requires >> admin address and smpt server data given in the config files. >> >> >> >> Thanks! >> >> >> .oO V Oo. >> >> >> >> On 12/01/2011 05:42 PM, Chris McDonough wrote: >> >>> On Thu, 2011-12-01 at 17:30 +0100, Vlad K. wrote: >>> >>>> Hello all! >>>> >>>> >>>> What is the recommended way to fetch registry (settings) for read only >>>> outside of the view (where request object is not available)? I was >>>> looking at the threadlocal.get_current_registry() but the docs say it >>>> should not be used except maybe in unit tests. >>>> >>>> I understand that the request object should be passed around, but what >>>> are my options if I want to avoid that? >>>> >>> To avoid passing deployment settings values around, your options are: >>> >>> - Use get_current_registry() >>> >>> - Use a pattern like >>> >>> http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/configuration.html#django-style-settings-py-configuration >>> >>> You're encouraged to pass per-request values around to make writing unit >>> tests pleasant and to make it possible to use more than one Pyramid app >>> per process. But... >>> >>> If you don't care about testing but you do care about being able to run >>> more than one instance of the application in the same process: >>> >>> def get_setting(setting_name, default=None): >>> return get_current_registry().settings.get('a', default) >>> >>> def somefunction(a, b): >>> beinghosed = get_setting('i-am-hosing-myself') >>> >>> If you care neither about testing nor about being able to run more than >>> one Pyramid application per process, the "django-style settings" >>> cookbook entry linked above puts the gun in your hands; it's pre-pointed >>> at your feet. >>> >>> - C >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/pylons-discuss?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
