On Wed, Sep 29, 2010 at 3:36 AM, Aaron Bentley <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Robert, > > A while ago, you suggested that we should use lp.services.timeline for > bzr calls. Is there documentation about how to use lp.services.timeline > regardless of the execution context? > > The examples I've been able to find use > get_request_timeline(get_current_browser_request()).
Thats the blessed pattern, yes. > But does > get_current_browser_request always work? It never raises; it may return None. > What about web service > requests? Totally fine AFAICT > What about cron scripts? The standard pattern works with cron scripts, but the ugly goes bone deep: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/623199 documents a fundamental problem with cron scripts. In short, we have two separate concepts for 'request that triggered this work', one (set_current_request_started) that works everywhere, and one (the participation mechanism) that currently only works in appserver requests. This is a driving force behind cronscripts having a different security policy, behind feature flags having its own thread locals, and other similar knock on effects. timelines have a similar workaround, so that the code we write today can look correct and we can fix the mess later. > And if get_current_browser_request always works, can we put it in > get_request_timeline instead of typing it explicitly every time? So there are two disconnected steps: - get a request from some context - get the timeline from that request (which will use IAnnotations once bug 623199 is fixed) I'm not too keen on conflating these steps; we could certainly add a new helper get_current_browser_request_timeline() though, that would be fine. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
