launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, Sep 29, 2010 at 3:36 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> 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