Merge lp:~wallyworld/launchpad/sharing-view-batching4-957663 into lp:launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | j.c.sackett | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 14999 | ||||
Proposed branch: | lp:~wallyworld/launchpad/sharing-view-batching4-957663 | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
548 lines (+165/-100) 9 files modified
lib/lp/registry/browser/pillar.py (+7/-8) lib/lp/registry/browser/tests/test_pillar_sharing.py (+13/-9) lib/lp/registry/interfaces/accesspolicy.py (+3/-3) lib/lp/registry/interfaces/sharingservice.py (+13/-2) lib/lp/registry/model/accesspolicy.py (+45/-11) lib/lp/registry/services/sharingservice.py (+20/-17) lib/lp/registry/services/tests/test_sharingservice.py (+53/-42) lib/lp/registry/templates/pillar-sharing.pt (+1/-1) lib/lp/registry/tests/test_accesspolicy.py (+10/-7) |
||||
To merge this branch: | bzr merge lp:~wallyworld/launchpad/sharing-view-batching4-957663 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
j.c.sackett (community) | Approve | ||
Richard Harding (community) | code* | Approve | |
Review via email: mp+98820@code.launchpad.net |
Commit message
Improve sharing service and access policy interfaces and rework queries to only load person objects once per batch.
Description of the change
== Implementation ==
Improve sharing service and access policy interfaces and rework queries to only load person objects once per batch.
Example of interface change:
The IAccessPolicyGr
Also, the pillar sharing view had some methods changed to properties.
Before batching all the data for the view was loaded in a single query, joining Person, AccessPolicy and AccessPolicyGra
SQL tracing shows that the batching infrastructure executes the core batching query twice due to a decorated result set being used. This is unfortunate. But I don't think the 2nd execution instantiates person objects.
== Tests ==
Check the existing tests run:
test_accesspolicy
test_sharingservice
test_pillar_sharing
The above ensures that external facing interfaces (eg those providing data to the view) work as before. Some of the tests needed tweaking due to the AccessPolicy model interface changes.
== Lint ==
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
Hey Ian--
This mostly looks good; I just have one question below.
> === modified file 'lib/lp/ registry/ browser/ pillar. py' registry/ browser/ pillar. py 2012-03-21 14:30:16 +0000 registry/ browser/ pillar. py 2012-03-22 13:04:20 +0000 launchpad. default_ batch_size, StormRangeFacto ry(sharees) ) igator` for sharees.""" navigator is None: hareeData( ) sharees navigator = self._getBatchN avigator( unbatchedSharee s) navigator Data(self) : sharees( self): gService( ).getPillarShar ees(self. context)
> --- lib/lp/
> +++ lib/lp/
> @@ -303,15 +303,17 @@
> size=config.
> range_factory=
>
> - def shareeData(self):
> - """Return an `ITableBatchNav
> + @property
> + def sharees(self):
> + """An `IBatchNavigator` for sharees."""
> if self._batch_
> - unbatchedSharees = self.unbatchedS
> + unbatchedSharees = self.unbatched_
> self._batch_
> return self._batch_
>
> - def unbatchedSharee
> - """Return all the sharees for a pillar."""
> + @property
> + def unbatched_
> + """All the sharees for a pillar."""
> return self._getSharin
>
> def initialize(self):
I'm not sure I understand the logic of making these properties; don't we
usually avoid that for things that might be expensive or slow, like
unbatched_sharees?