Merge lp:~wgrant/launchpad/bugsummary-v2-db-0 into lp:launchpad/db-devel
Status: | Merged |
---|---|
Approved by: | Stuart Bishop |
Approved revision: | no longer in the source branch. |
Merged at revision: | 11735 |
Proposed branch: | lp:~wgrant/launchpad/bugsummary-v2-db-0 |
Merge into: | lp:launchpad/db-devel |
Prerequisite: | lp:~wgrant/launchpad/bugsummary-v2-db-0-untouched |
Diff against target: |
668 lines (+194/-298) 2 files modified
database/schema/patch-2209-19-0.sql (+186/-290) database/schema/security.cfg (+8/-8) |
To merge this branch: | bzr merge lp:~wgrant/launchpad/bugsummary-v2-db-0 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Stuart Bishop (community) | db | Approve | |
Robert Collins | db | Pending | |
Review via email: mp+113008@code.launchpad.net |
Commit message
First DB phase of BugSummary v2: adding unpopulated access_policy, changing to a task-driven trigger set.
Description of the change
This branch begins the DB side of the BugSummary access rework (using access policies and grants rather than bug subscriptions).
The main change is the addition of an access_policy column. It's currently always null, so appservers can be taught to filter on it properly before we start leaking data. I also made fixed_upstream (already removed from the app code) default to false in preparation for its removal.
Those two schema changes only make up a tiny portion of the overall DB changes. Most of the rest restructures things to perform less badly and make it easier to populate access_grants later. Rather than triggering on and joining across Bug+BugTask+
This means that BugSummary journaling becomes BugTask-based rather than Bug-based, significantly changing its performance characteristics. In the old world, journaling a full bug (on a duplicateof, has_patch, information_type or tag change) would write n*(tasks + distinct_
The change to a task-based approach also changes the counts slightly: each task on a package contributes to the distribution's counts on its own, rather than each bug with a task on a package contributing only once. So counts that involve bugs with multiple package tasks for a single distribution will see an increase. This new behaviour matches bugsummaryrebuild and the counting method we've used in bug search listings forever, and it's far easier to implement efficiently. This change will mean we have more wildly exaggerated counts until we do a rebuild of the table, but I intend to do one as soon as I verify that the patch performs as expected on production.
I also dropped some foreign key constraints from the journal. The table (bugsummaryjournal) is maintained by triggers on a table (bugtaskflat) maintained by triggers on columns that have foreign keys, and it can be readily rebuilt if a bug causes corruption, so the foreign keys serve only to hinder performance. Testing shows that it can actually speed things up significantly.
The diff is pretty hideous, but I've specified a prereq branch with the original functions to hopefully make things a bit more sensible.
Discussed some on IRC. Existing tests will provide the best review.