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 |
Related bugs: |
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(
Description of the change
Now that SSO is separate, EmailAddress.
To post a comment you must log in.
> +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 amcache view. We might
NULL here, although we do in the validpersonorte
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 validpersonorte amcache 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.