launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

In this episode, I learnt how to batch things (thanks Curtis!) and
have hopefully fixed the mailing list moderation page for now.

batch_navigation.txt was really lacking as a tutorial, so I took
comprehensive notes. I guess I'll roll them into that file at some
point, but for now, to make sure its 'out there'...

here's how you batch an existing page. For an example see rev 11544 on devel.
--------
Firstly, the page is probably doing a tal:repeat on some result set
attribute of the view /model.

If its on the model, make a view variant of it.

if its on the model, we'll edit the existing thing.

Wrap the resultset with BatchNavigator.
Existing users (for view based attributes) need to be updated to use
attribute.currentBatch() instead.

The attribute should be a cachedproperty, as it is accessed several
times in the template later.

When creating the BatchNavigator either use a subclass, or pass
size=xxx to control the batch size (or do nothing to use the default
batch size).

After creating it, use setHeadings() to set the headings (if you don't
want the defaults), or alternatively subclass. (Don't subclass, its
not needed).
The request parameter to BatchNavigator is what glues the slicing data
into the batch.

Tests for this:
 - the view attribute should be a BatchNavigator
 - the heads should be set appropriately.

Now, update the template(s) that were iterating the underlying resultset.

(Note, if you're in a metal:form, you need to ensure that you have one
div for the widgets slot, and have the below within that)

You want to end up with roughly:

<tal:navigation replace="structure view/ATTRIBUTE/@@+navigation-links-upper" />
<ul tal:define="THINGS view/ATTRIBUTE/currentBatch">
  <li tal:repeat="THING THINGS">
    <name tal:replace="THING/WHATEVERt" />
  </li>
</ul>
<tal:navigation replace="structure view/ATTRIBUTE/@@+navigation-links-lower" />

For this, check that the batching works by rendering the template with
a request with batch=1, and 2 objects to render.

Also check that the nav classes are rendered correctly:
find_tag_by_id(admin_browser.content, 'upper-batch-nav-batchnav-next')['class']
(And lower) for the other one.
-----------

Tim and I had a long chat about the codeimportmachine XMLRPC timeouts,
and I've filed a bug and an RT as a result of that: Its the most
direct evidence we've had so far of cross-thread contention (of some
sort) in the appservers; I think its time we tried a single-thread
appserver experiment. This is the 2nd highest OOPS at the moment, so
its quite important to fix.

And then we found that there was a fairly serious production issue -
it had crept in with my timeline work late last release but wasn't
identified as a clear issue till the downtime in the weekend - and we
thought it was related then, when it kept happening today, we got deep
enough into it to identify and fix the cause.

The new request timeline code was breaking the oops generation code when:
 - the timeout was when a sql request *was not emitted*
 - the oops code tried to send a sql statement itself.

This is now fixed in prod via a cowboy and will be fixed on edge when
Jeroen's fix for the Python2.6 issue lands and gets deployed.

Oh, and rolling in some stuff from yesterday, we now have more scopes
available and more things controlled by feature flags.

The current (manual) list is on the bottom of
https://dev.launchpad.net/LEP/FeatureFlags.

-Rob