Hi, Robert. On Wed, Feb 23, 2011 at 3:35 PM, Robert Collins <[email protected]> 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/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
