Merge lp:~leonardr/lazr.restful/enforce-version-order into lp:lazr.restful
Proposed by
Leonard Richardson
on 2010-01-28
| Status: | Merged |
|---|---|
| Merged at revision: | not available |
| Proposed branch: | lp:~leonardr/lazr.restful/enforce-version-order |
| Merge into: | lp:lazr.restful |
| Diff against target: |
256 lines (+159/-24) 3 files modified
src/lazr/restful/docs/webservice-declarations.txt (+85/-22) src/lazr/restful/metazcml.py (+72/-0) src/lazr/restful/simple.py (+2/-2) |
| To merge this branch: | bzr merge lp:~leonardr/lazr.restful/enforce-version-order |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Paul Hummer (community) | 2010-01-28 | Approve on 2010-01-28 | |
|
Review via email:
|
|||
To post a comment you must log in.
| Leonard Richardson (leonardr) wrote : | # |
| Leonard Richardson (leonardr) wrote : | # |
I should mention that I refactored some code in webservice-
lp:~leonardr/lazr.restful/enforce-version-order
updated
on 2010-01-28
- 108. By Leonard Richardson on 2010-01-28
-
Clarified explanation in doctest.:
- 109. By Leonard Richardson on 2010-01-28
-
Changed 'after' to 'on top' to fit better with the stack metaphor.
| Paul Hummer (rockstar) wrote : | # |
Hi Leonard-
Sorry this took so long. I ended up having to look at a lot more code than what is in the patch. This lazr.restful stuff is a bit more involved than I thought. These changes all look good though. Please land it.
Cheers,
Paul
review:
Approve

This branch adds two bits of multiversion- related error checking.
1. Named operations are annotated with a stack of version information. The most recent version is supposed to be at the top of the stack.
This is right:
@operation_ for_version( "2.0") for_version( "1.0") for_version( "beta")
...
@operation_
...
@operation_
This is wrong:
@operation_ for_version( "2.0") for_version( "beta") for_version( "1.0")
...
@operation_
...
@operation_
The ensure_ correct_ version_ ordering function looks up the canonical version ordering in the IWebServiceConf iguration implementation, and makes sure every named operation is annotated with a consistent ordering. If the developer makes a mistake, ensure_ correct_ version_ ordering raises an AssertionError explaining the problem and giving the correct ordering.
This code has to run in the second stage of ZCML processing, rather than when the annotations are initially processed, because until the IWebServiceConf iguration utility becomes available, there's no way to know whether version "foo" comes before or after version "bar".
2. If a named operation is not published in a certain version, it makes no sense to annotate it for that version.
@export_ operation_ as("its_ gone_in_ 1_0") <--This annotation is stupid! removed_ in_version( "1.0") as_read_ operation( )
@operation_
@export_
The register_ webservice_ operations method will now make sure there are no extra annotations for a version in which a named operation is not published. If there are any extra annotations, it will raise an AssertionError and complain about them.
This code has to run in the second stage of ZCML processing because by then all the annotations have been processed. If I make each annotations in charge of complaining when it's applied to an unpublished method, it'll reject cases in which the method seems unpublished at the time but gets published later.
@export_ as_read_ operation( ) operation_ as("its_ redefined_ in_1_0" ) <--This looks stupid, but turns out to be valid! removed_ in_version( "1.0") as_read_ operation( )
@export_
@operation_
@export_
This set of annotations is sloppier than this one:
@export_ operation_ as("its_ redefined_ in_1_0" ) <--This is clearly valid! as_read_ operation( ) removed_ in_version( "1.0") as_read_ operation( )
@export_
@operation_
@export_
But that's not worth raising an error about.