launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

On Wed, 25 Aug 2010 07:20:29 +1200, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:

> I have, however, run into some nasty cruft where the webapp 'adapter'
> module has a very different idea about 'request is active' to what
> zope does. Zope looks at participations; the adapter module looks at
> thread local. This is kindof the very thing I'm worried about with
> eventually adding in AJAX and so on - so I'm sttuborning it out and
> trying to keep the new code very clean and decoupled; I may give up
> soon and collapse the tracking component back into the core. I've
> filed http:/pad.lv/623199 about this - its may be  a dupe, but there
> are workaround comments pointing this out without bug references (like
> lib/canonical/launchpad/scripts/__init__.py line 115) so I'm hopeful
> that it isn't. Fixing 623199 will probably let us make a lot of code -
> the launchpad, the webapp adapter, errorlogging and so on a lot
> cleaner.

Well.  I *entirely* support reducing the number of thread-locals we have
knocking around.  Also, it just plain makes sense that a log of the sql
statements executed in processing a request is associated with ... the
request.  For the webapp, I expect this to all work nicely with little
friction.

The question then is, what happens in the non-webapp context?  Well, I
guess really it is: what do we *want* to happen in the non-webapp
context?  I think perhaps we shouldn't be expecting
get_current_browser_request() to return something outside the webapp.

Specifically, I don't think:

<lifeless> mwhudson: making scripts have an IRequest always, so that
           when they do sql it is logged in my new code

is actually something we want to do.

I think we should implement get_participation_implementing() (which
would take an interface) and (a) reimplement get_current_browser_request
in terms of that (b) actually say something closer to what we mean.  I
think it's worth remembering that we don't have to stick to the
interface hierarchy Zope provides here, all the requests the app servers
use are custom classes already, so if we want to add another interface
to the mix we can.  I say this because it makes sense to use
request.annotations in the object timeline stuff, but 'annotations' is
in IApplicationRequest which also includes other things that don't
really make sense outside the webapp (like bodyStream).  So how about we
define an interface, IParticipationWithAnnotations say, and make sure
that scripts set up a participation that implements this.

On the how-do-we-get-there-from here side of things, I'm not really
sure.  I think we probably just need pass a
participation-that-implements-IParticipationWithAnnotations to the call
to setupInteraction in execute_zcml_for_scripts, if we're happy with a
single interaction/participation for the entire length of the script.

We then need to make LaunchpadBrowserRequest and LaunchpadTestRequest
implement IParticipationWithAnnotations, write
get_participation_implementing() and call it from the timeline code.

In due course we can use this approach to simplify much of our code, I
expect, but for now, I think we can just do it for the timeline stuff.

I hope this helps.

Cheers,
mwh