On 14/06/12 16:17, Chris McDonough wrote: >> Well, I know that authors are not happy with overall design, as >> explained here http://plope.com/pyramid_auth_design_api_postmortem (and >> I have to say I agree with this post 100%), but principals idea is there >> anyway, so why not make it more efficient? > > Becase, eventually, someone will need to clear the cache when the list > of effective principals changes as the result of something happening > during a request, such as the current user obtaining a new group or > losing a group. Since the way principals are computed is > application-specific, the framework itself can't know when this > happens, and so it can't clear any cache automatically. And rather > than violating rule of least surprise wrt the freshness of the list of > effective principals and a framework-level cache, we leave it up to > the application to do the caching and clearing of that cache. I just mean storing it for the single request, not a full-blown cache spanning multiple requests. Just to avoid querying it multiple times per request.
Or do you mean it can change in the middle of a single request? That's a scary idea :) > > But as noted by that post, the groupfinder abstraction is dumb. > People should just create a new authentication policy or subclass an > existing policy. When you do this, there's a natural place to add > caching. Exactly. Thanks! Przemek -- 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.
