Merge lp:~lifeless/launchpad/registry into lp:launchpad
| Status: | Merged | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Approved by: | Curtis Hovey on 2010-08-09 | ||||||||||||||||
| Approved revision: | no longer in the source branch. | ||||||||||||||||
| Merged at revision: | 11367 | ||||||||||||||||
| Proposed branch: | lp:~lifeless/launchpad/registry | ||||||||||||||||
| Merge into: | lp:launchpad | ||||||||||||||||
| Diff against target: |
835 lines (+396/-56) 12 files modified
lib/canonical/cachedproperty.py (+145/-4) lib/canonical/database/sqlbase.py (+12/-0) lib/canonical/launchpad/database/librarian.py (+1/-0) lib/lp/registry/doc/teammembership.txt (+2/-1) lib/lp/registry/interfaces/person.py (+19/-7) lib/lp/registry/model/distribution.py (+4/-3) lib/lp/registry/model/person.py (+160/-35) lib/lp/registry/model/product.py (+1/-2) lib/lp/registry/tests/test_person.py (+40/-2) lib/lp/soyuz/model/archive.py (+8/-2) lib/lp/translations/model/potemplate.py (+1/-0) lib/lp/translations/model/potmsgset.py (+3/-0) |
||||||||||||||||
| To merge this branch: | bzr merge lp:~lifeless/launchpad/registry | ||||||||||||||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Henning Eggers (community) | code | 2010-08-09 | Approve on 2010-08-16 |
| Curtis Hovey (community) | code | 2010-08-09 | Approve on 2010-08-09 |
|
Review via email:
|
|||
Commit Message
Reduce the query count for team/participants to 11 from hundreds for ubuntu-dev.
Description of the Change
Make the /participation API make a constant number of DB calls, rather than scaling per-team-member found.
This change has a few key components.
First, the existing allmembers attribute is perserved unaltered; rather a new all_members_
A common helper, _all_members is created on Person, which can prepopulate various attributes.
Secondly, all the attributes that are exported as fields, which the API wants to examine, are prepopulated, bringing the query count down to 11 for a team with 3 members (from nearly 40 - and that 11 is now constant in tests).
The prepopulation is done via cachedproperty decorators, which should be totally fine for webservice and API requests but does introduce a risk that other scripts which acccess these properties, and read-them-
I haven't run a full test suite yet, I will be doing so to find out if there are any side effects which will need fixing.
All that said, I think this is a more robust approach than having a separate CachedPersonDec
| William Grant (wgrant) wrote : | # |
I think all POSTs redirect before displaying the subsequent page, so that should be fine. However, I'm very suspicious of widely deploying @cachedproperty... I'd be much happier if it was populated only by the explicit prejoin, and operated uncached in the normal case.
| Robert Collins (lifeless) wrote : | # |
On Tue, Aug 10, 2010 at 8:59 PM, William Grant <email address hidden> wrote:
> I think all POSTs redirect before displaying the subsequent page, so that should be fine. However, I'm very suspicious of widely deploying @cachedproperty... I'd be much happier if it was populated only by the explicit prejoin, and operated uncached in the normal case.
We /need/ a strategy for doing non-collection derived data in the
model, or we'll be playing 'omfg this is ugly shit', forever - and
never getting things fast.
Most of our pages only access 3 or 4 linked collections of objects,
but they generally do well over a hundred queries: this is
pathological!
I think its better that we experiment and find the problems and fix
them, than push back on actually getting what we need in place by
making the problem bigger than it is: cachedproperty isn't ideal, but
its a very small amount of work to use it.
-Rob
| Robert Collins (lifeless) wrote : | # |
This needs an incremental review.
Please ignore the cachedproperty.py changes other than those in rev 11324 - they are in my separate, approved, lp:~lifeless/launchpad/cachedproperty branch - that I started after this review, but merged in because it makes the branch cleaner and leaner.
You could pull that branch and merge this into it to see the incremental changes.
I'm particularly interested in the removeSecurityProxy calls in cachedproperty.py: I think they are appropriate and needed, but perhaps not?
The change in 11323 to invalidate the cache on Person is definitely needed and an expected consequence of more model object caching; taste wise we probably want to iterate towards an interface where the cache description ('_archive_cached') matches the cache attribute ('.archive') - but I think that that is essentially polish, not a prerequisite.
| Henning Eggers (henninge) wrote : | # |
Hi Robert,
thanks for all this work. We talked about the use of removeSecurityProxy in cachedproperty.py. It has to be clear that these are low-level functions that don't care about security. Security has to be considered as each call site. So this is mainly a documentation issue.
Please use "naked_instance" in the functions, though, to be clear about it.
Also, we agreed that you file a tech-debt bug about moving the code to lp.services and creating an extra doctest file instead of tests in docstring. Adding a unittest for extra points. ;-)
We will have to watch how these functions will be used in the future.
Cheers,
Henning

I am very pleased to see this enhancement. I expressed concerns that the @cachedproperty on is_valid_person and archive may cause issues during updated and subsequent displays of the person. eg, A user chooses to deactivate his profile, then the page loads and says he is still active, but reloading the page shows the page is deactivated. I am speculating though.
I think this is good to land. We will be prepared to address @cachedproperties as we do with Person. preferredemail, where the mutator function delete the _*_cached property to clear the state.