Merge lp:~abentley/launchpad/celery-everywhere-9 into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | j.c.sackett on 2012-04-26 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 15175 |
| Proposed branch: | lp:~abentley/launchpad/celery-everywhere-9 |
| Merge into: | lp:launchpad |
| Prerequisite: | lp:~abentley/launchpad/celery-everywhere-8 |
| Diff against target: |
713 lines (+228/-173) 5 files modified
lib/lp/answers/model/questionjob.py (+10/-2) lib/lp/answers/tests/test_questionjob.py (+106/-117) lib/lp/services/job/model/job.py (+4/-1) lib/lp/soyuz/model/packagecopyjob.py (+14/-2) lib/lp/soyuz/tests/test_packagecopyjob.py (+94/-51) |
| To merge this branch: | bzr merge lp:~abentley/launchpad/celery-everywhere-9 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| j.c.sackett (community) | 2012-04-26 | Approve on 2012-04-26 | |
| Richard Harding (community) | code* | 2012-04-26 | Approve on 2012-04-26 |
|
Review via email:
|
|||
Commit Message
Support running QuestionJob and PlainPackageCopyJob via Celery.
Description of the Change
= Summary =
Support running QuestionJob and PackageCopyJob via Celery.
== Pre-implementation notes ==
None
== LOC Rationale ==
Part of a resourced arc that will remove code.
== Implementation details ==
Clean up test set up for both sets of tests. Add makeDerived methods to support UniversalJobSource, and QuestionJob and PackageCopyJob support to UniversalJobSource.
Use EnumeratedSubclass as the metatype for PackageCopyDerived, to support makeDerived method.
Add config members to jobs to support UniversalJobSource, which uses this to determine database user.
Extract simplified test setup.
Add TestViaCelery test cases for both classes.
== Tests ==
bin/test -vm 'test_questionj
== Demo and Q/A ==
None
= 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/
lib/lp/
lib/lp/
| Aaron Bentley (abentley) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12-04-26 02:33 PM, Richard Harding wrote:
> Review: Approve code*
>
> Thanks Aaron, couple questions, but looks good and ok'ing:
>
> - I'm curious why you didn't make the make_question_job into a
> factory method and use it like the other factory createXXXX
> methods?
I wanted to use it with multiple classes. If it had been a method, I
wouldn't have been able to do that.
> - I know it's just in testing, but with
> make_user_
> namedtuple or dictionary coming back. Keeping the right params in
> the right order is more likely to break.
I've never encountered a namedtuple in Launchpad code, nor seen a
dictionary used that way. I don't we should disparage returning
multiple values; it's a key Python feature.
Also, I just moved that code around-- it already returned multiple values.
> - In the final test can you add a check for some bit of the email
> to make sure it's the one you're expecting.
There are thorough tests to ensure that the output email is correct.
The purpose of this test is to check the integration with Celery.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk+
+NsAoIUuxjBhTtt
=JztV
-----END PGP SIGNATURE-----
| j.c.sackett (jcsackett) wrote : | # |
Aaron--
I'm guessing the rationale for make_question_job is that there's no need for it outside that file? As such I'm fine with not adding it to the factory.
Rick's point about named tuple is a good one, but I think it's very optional. I agree with his request for the additional check, though.
| Aaron Bentley (abentley) wrote : | # |
> I'm guessing the rationale for make_question_job is that there's no need for
> it outside that file? As such I'm fine with not adding it to the factory.
Right. It's not a generic function to create a QuestionJob, it's specifically for (some of) these tests.
> Rick's point about named tuple is a good one, but I think it's very optional.
> I agree with his request for the additional check, though.
Okay.

Thanks Aaron, couple questions, but looks good and ok'ing:
- I'm curious why you didn't make the make_question_job into a factory method and use it like the other factory createXXXX methods?
- I know it's just in testing, but with make_user_ subject_ body_headers it'd be great to have either a namedtuple or dictionary coming back. Keeping the right params in the right order is more likely to break.
- In the final test can you add a check for some bit of the email to make sure it's the one you're expecting.