launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

Hi, Robert.

On Wed, Feb 23, 2011 at 3:35 PM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:
> There are a few bugs around bug heat. This particular one appears to
> be negatively impacting package copying, and from my reading of the
> code bug filing and retargeting etc also triggers a cache update on
> the context.
>
> In the short term, I think we need to keep the current implementation
> of the heat cache, though we did discuss some improvements that would
> be more efficient @ the epic.
>
> However, are there any issues with just-in-time updates of the cache
> and depending on the backend updates (which I believe is job based)
> instead?
>
> Alternatively, we could move to an incremental algorithm: add the
> delta of the bugs heat to the target's total, change the max IF the
> bug has the contexts peak heat already.
>
> Your thoughts solicited :)
>

Is the question -- can the stuff in recalculateBugHeatCache be moved
out from the model and into an offline job?  If so, then yes, I think
that could happen.

The only jobs for heat that are run now are run to decay the heat on
bugs that haven't seen activity for awhile.  Heat itself is calculated
in a trigger and only for individual bugs.  This function gets the
aggregate values for max heat (and sometimes total and count) for the
project, package, or what have you.  So I don't see any reason this
couldn't be pushed into an offline job.  This is for the upper number
for lighting the flames on the heat icon mostly, so I don't see much
downside actually.

Cheers,
deryck


-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/