Merge lp:~gmb/launchpad/add-bugheatjob-table into lp:launchpad/db-devel
| Status: | Merged |
|---|---|
| Approved by: | Graham Binns on 2010-01-19 |
| Approved revision: | not available |
| Merged at revision: | not available |
| Proposed branch: | lp:~gmb/launchpad/add-bugheatjob-table |
| Merge into: | lp:launchpad/db-devel |
| Diff against target: |
34 lines (+17/-0) 2 files modified
database/schema/comments.sql (+6/-0) database/schema/patch-2207-28-0.sql (+11/-0) |
| To merge this branch: | bzr merge lp:~gmb/launchpad/add-bugheatjob-table |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Stuart Bishop | db | 2010-01-18 | Approve on 2010-01-19 |
| Jonathan Lange (community) | db | 2010-01-18 | Approve on 2010-01-18 |
|
Review via email:
|
|||
Commit Message
Add a BugHeatJob table to the database.
| Graham Binns (gmb) wrote : | # |
| Jonathan Lange (jml) wrote : | # |
Looks good to me. I think it's a Good Thing to follow the branch job pattern here: more code re-use potential.
Also, maybe this will make it easier to use jobs for other things in the bugs app.
| Stuart Bishop (stub) wrote : | # |
The id column needs to be of type 'serial PRIMARY KEY', not 'integer PRIMARY KEY'.
Otherwise the DB patch is fine. patch-2207-
I wouldn't mind rejecting this though, as we appear to be building our own messaging system instead of using a messaging system. Other job tables are for longer running tasks where we need to store state during the run - we might need them even if we switched from a poll based notification to a pull based using RabbitMQ or similar. The use cases for BugJob I can imagine are just using this table as a queue.
| Graham Binns (gmb) wrote : | # |
On Tue, Jan 19, 2010 at 03:26:36AM -0000, Stuart Bishop wrote:
> Review: Approve db
> The id column needs to be of type 'serial PRIMARY KEY', not 'integer PRIMARY KEY'.
>
> Otherwise the DB patch is fine. patch-2207-
Thanks.
> I wouldn't mind rejecting this though, as we appear to be building our
> own messaging system instead of using a messaging system. Other job
> tables are for longer running tasks where we need to store state
> during the run - we might need them even if we switched from a poll
> based notification to a pull based using RabbitMQ or similar. The use
> cases for BugJob I can imagine are just using this table as a queue.
I agree. However, time constraints for getting this working (it turns
out that we need it RSN for both bug heat and fixing checkwatches) mean
that we need to go ahead with the less perfect solution.
The sooner we can get to using RabbitMQ, the better.

This branch adds a DB patch to create a BugHeatJob table. Bug heat calculation jobs will use this table to work out which bug they need to update.