On Tue, Jan 19, 2010 at 10:48 PM, Karl Fogel <email address hidden> wrote:
> We talked to gmb and decided to let NULL represent "this bug's heat has never been updated", since that's consistent with what other timestamp fields in Launchpad do. We don't want to use CURRENT_TIMESTAMP because if for some reason the set-heat-on-bug-creation job fails, we want the hourly cron script that chooses bugs to update based on heat_last_updated to pick this one up, and if it claims its heat was recently updated it might get ignored.
>
> We added a comment to comments.sql indicating this.
For the record, we have examples of both approaches in the DB, which is why it was worth documenting this.
As the heat is being calculated asynchronously in a separate transaction, after the Bug has been created, I think the correct choice has been made.
On Tue, Jan 19, 2010 at 10:48 PM, Karl Fogel <email address hidden> wrote: on-bug- creation job fails, we want the hourly cron script that chooses bugs to update based on heat_last_updated to pick this one up, and if it claims its heat was recently updated it might get ignored.
> We talked to gmb and decided to let NULL represent "this bug's heat has never been updated", since that's consistent with what other timestamp fields in Launchpad do. We don't want to use CURRENT_TIMESTAMP because if for some reason the set-heat-
>
> We added a comment to comments.sql indicating this.
For the record, we have examples of both approaches in the DB, which is why it was worth documenting this.
As the heat is being calculated asynchronously in a separate transaction, after the Bug has been created, I think the correct choice has been made.
-- www.stuartbisho p.net/
Stuart Bishop <email address hidden>
http://