Merge lp:~wgrant/launchpad/validpersoncache-no-emailaddress-account into lp:launchpad/db-devel

Proposed by William Grant
Status: Merged
Merged at revision: 11278
Proposed branch: lp:~wgrant/launchpad/validpersoncache-no-emailaddress-account
Merge into: lp:launchpad/db-devel
Diff against target: 34 lines (+30/-0)
1 file modified
database/schema/patch-2209-01-0.sql (+30/-0)
To merge this branch: bzr merge lp:~wgrant/launchpad/validpersoncache-no-emailaddress-account
Reviewer Review Type Date Requested Status
Stuart Bishop (community) db Approve
Robert Collins (community) Approve
Review via email: mp+87450@code.launchpad.net

Commit message

Switch ValidPerson(OrTeam)Cache to use EmailAddress.person instead of EmailAddress.account.

Description of the change

Now that SSO is separate, EmailAddress.account is redundant with Person.account. Before we can do away with the former, the ValidPerson(OrTeam)Cache views must be adjusted to use EmailAddress.person.

To post a comment you must log in.
Revision history for this message
Stuart Bishop (stub) wrote :

> +CREATE OR REPLACE VIEW validpersoncache AS (
> +    SELECT emailaddress.person AS id
> +    FROM emailaddress, person, account
> +    WHERE
> +        emailaddress.person = person.id
> +        AND person.account = account.id
> +        AND emailaddress.person IS NOT NULL
> +        AND emailaddress.status = 4
> +        AND account.status = 20
> +);

The emailaddress.person IS NOT NULL clause is redundant, as the first
clause means it will never be NULL.

It is interesting that we don't currently check that person.merged IS
NULL here, although we do in the validpersonorteamcache view. We might
have assumed it was redundant as merged person records will never have
an account? In which case it would have guarded against bad data for
no real cost. I guess we should leave it as it is as I think this view
is only used by legacy code.

> +CREATE OR REPLACE VIEW validpersonorteamcache AS (
> +    SELECT person.id
> +    FROM
> +        person
> +        LEFT JOIN emailaddress ON person.id = emailaddress.person
> +        LEFT JOIN account ON person.account = account.id
> +    WHERE
> +        person.teamowner IS NOT NULL
> +        AND person.merged IS NULL
> +        OR person.teamowner IS NULL
> +        AND account.status = 20
> +        AND emailaddress.status = 4
> +);

I like brackets in mixed AND and OR statements so I don't need to
worry about precedence, rules :)

I just looked at using UNION ALL for the second view, but the
estimates are slightly slower.

Revision history for this message
Robert Collins (lifeless) wrote :

what stub says.

review: Approve
Revision history for this message
Stuart Bishop (stub) :
review: Approve (db)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== added file 'database/schema/patch-2209-01-0.sql'
2--- database/schema/patch-2209-01-0.sql 1970-01-01 00:00:00 +0000
3+++ database/schema/patch-2209-01-0.sql 2012-01-04 10:54:25 +0000
4@@ -0,0 +1,30 @@
5+-- Copyright 2012 Canonical Ltd. This software is licensed under the
6+-- GNU Affero General Public License version 3 (see the file LICENSE).
7+SET client_min_messages=ERROR;
8+
9+CREATE OR REPLACE VIEW validpersoncache AS (
10+ SELECT emailaddress.person AS id
11+ FROM emailaddress, person, account
12+ WHERE
13+ emailaddress.person = person.id
14+ AND person.account = account.id
15+ AND emailaddress.status = 4
16+ AND account.status = 20
17+);
18+
19+CREATE OR REPLACE VIEW validpersonorteamcache AS (
20+ SELECT person.id
21+ FROM
22+ person
23+ LEFT JOIN emailaddress ON person.id = emailaddress.person
24+ LEFT JOIN account ON person.account = account.id
25+ WHERE
26+ (person.teamowner IS NOT NULL
27+ AND person.merged IS NULL)
28+ OR
29+ (person.teamowner IS NULL
30+ AND account.status = 20
31+ AND emailaddress.status = 4)
32+);
33+
34+INSERT INTO LaunchpadDatabaseRevision VALUES (2209, 01, 0);

Subscribers

People subscribed via source and target branches

to status/vote changes: