Merge lp:~jcsackett/launchpad/shortlist-696913 into lp:launchpad
Status: | Merged |
---|---|
Approved by: | j.c.sackett |
Approved revision: | no longer in the source branch. |
Merged at revision: | 12194 |
Proposed branch: | lp:~jcsackett/launchpad/shortlist-696913 |
Merge into: | lp:launchpad |
Diff against target: |
359 lines (+149/-30) 7 files modified
lib/lp/blueprints/interfaces/specificationtarget.py (+5/-4) lib/lp/blueprints/tests/test_hasspecifications.py (+38/-1) lib/lp/registry/interfaces/milestone.py (+5/-5) lib/lp/registry/interfaces/productseries.py (+5/-4) lib/lp/registry/tests/test_milestone.py (+38/-10) lib/lp/registry/tests/test_productseries.py (+20/-5) lib/lp/testing/matchers.py (+38/-1) |
To merge this branch: | bzr merge lp:~jcsackett/launchpad/shortlist-696913 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Edwin Grubbs (community) | code | Approve | |
Benji York (community) | code* | Approve | |
Jeroen T. Vermeulen (community) | Needs Fixing | ||
Review via email: mp+45938@code.launchpad.net |
Commit message
[r=benji,
Description of the change
Summary
=======
Because we are currently snapshotting most fields in pillars when snapshot is called for. However, certain collections don't need to be snapshotted, and cause an error because the number of objects in the collection exceed hardcoded limits.
This branch adds doNotSnapshot to those collections.
Proposed Fix
============
Add doNotSnapshot to the offending fields. A better solution would involve altering Snapshot to ignore (or be able to ignore) CollectionFields, but as this bug is holding up other work, the simple fix should be landed first. The better solution has been filed as bug 701715.
Preimplementation Talk
=======
Spoke with Curtis Hovey about the problem and the interactions of Snapshot and the various fields. Came up with both the simple fix and the more comprehensive one.
Implementation
==============
lib/lp/
lib/lp/
lib/lp/
-------
Added doNotSnapshot to the CollectionFields in IHasSpecifications and IHasMilestones. doNotSnapshot had to be added to IProductSeries milestone CollectionFields directly, b/c the interface redefines those fields, but they still connect to probable causes of the Shortlist error.
lib/lp/
lib/lp/
lib/lp/
-------
Added tests.
Test
====
bin/test -t test_productseries
bin/test -t test_milestone
bin/test -t test_hasspecifi
QA
==
On staging, hit the +edit or +configure* links for Launchpad. It should not error with shortlist
Lint
====
make lint output:
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
-------
Hi Jon,
I'm glad to see you address this nuisance. You'll make all our lives easier. Danilo was planning to look into it as well this week, since we were getting some of the errors on Translations, but this may just save him the time.
The big question I have though is: could this change confuse clients written to our 1.0 API? We made a promise to keep that API stable. Or do we consider it a plain bug in the client if it can't cope with a collection no longer being snapshotted?
I'm voting "needs fixing," but please don't take that as a vote of no confidence in your approach. It's merely that I'm requesting some changes to the test code that would probably warrant a new review round.
> === modified file 'lib/lp/ blueprints/ tests/test_ hasspecificatio ns.py' blueprints/ tests/test_ hasspecificatio ns.py 2010-11-29 18:04:07 +0000 blueprints/ tests/test_ hasspecificatio ns.py 2011-01-12 13:35:47 +0000
> --- lib/lp/
> +++ lib/lp/
> @@ -178,3 +184,49 @@ sOfSpecificatio nsAre( valid_specifica tions) nsSnapshotTestC ase(TestCaseWit hFactory) : nalLayer icationsSnapsho tTestCase, self).setUp()
> product=product, name="spec3")
> self.assertName
> ["spec1"], person.
> +
> +
> +class HasSpecificatio
> + """A TestCase for snapshots of specification targets."""
> +
> + layer = DatabaseFunctio
> +
> + def setUp(self):
> + super(HasSpecif
This method looks redundant. Might as well leave it out AFAICS.
> + def check_omissions (self, target, providing):
What omissions are being checked, exactly?
The word "omission" has strong negative connotations: it generally implies that something is missing that shouldn't be. If this method is meant to check that collections are _properly omitted_ from the snapshot, maybe there's some better word.
> + """snapshots of objects with IHasSpecification should not snapshot
> + marked attributes.
Please start your sentence with a capital letter!
This is a statement of fact, but the first line of a docstring is expected to describe what the method actually does for the caller.
> + wrap an export with 'donotsnapshot' to force the snapshot to not
> + include that attribute.
Please start your sentence with a capital letter!
Is the imperative an instruction to this method's caller? Or a description of what the method does in the imperative form? Or general advice to programmers?
> + """ providing)
> + snapshot = Snapshot(target, providing=
It's probably just my shallow understanding of Zope, but I would have expected "providing= IHasSpecificati ons" to work here.
> + omitted = [ ions', specifications' ,
> + 'all_specificat
> + 'valid_
> + ]
> + for attribute in omitted:
> + self.assertFalse(
> + hasattr(snapshot, attribute),
> + "snapshot should not include %s." % attribute)
Please start your sentence with a capital letter!
> === modified file 'lib/lp/ registry/ tests/test_ milestone. py' registry/ tests/test_ milestone. py 2010-10-04 19:50:45 +0000 registry/ tests/test_ milestone. py 2011-01-12 13:35:47 +0000
> --- lib/lp/
> +++ lib/lp/
> @@ -81,6 +91,48 @@
...