Merge lp:~leonardr/lazr.restful/promote-write-operation-to-mutator into lp:lazr.restful
Status: | Merged |
---|---|
Approved by: | Данило Шеган |
Approved revision: | 174 |
Merged at revision: | 172 |
Proposed branch: | lp:~leonardr/lazr.restful/promote-write-operation-to-mutator |
Merge into: | lp:lazr.restful |
Diff against target: |
231 lines (+102/-25) 4 files modified
src/lazr/restful/NEWS.txt (+11/-5) src/lazr/restful/docs/webservice-declarations.txt (+65/-5) src/lazr/restful/metazcml.py (+25/-14) src/lazr/restful/version.txt (+1/-1) |
To merge this branch: | bzr merge lp:~leonardr/lazr.restful/promote-write-operation-to-mutator |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Данило Шеган (community) | Approve | ||
Review via email: mp+49976@code.launchpad.net |
Description of the change
Let me explain this in terms of the class I used to test it.
>>> class IOperationPromo
... export_
...
... field = exported(
...
... @mutator_for(field)
... @operation_
... @operation_
... @export_
... @operation_
... def set_value(text):
... pass
The example web service has four versions: beta, 1.0, 2.0, and 3.0. In 'beta', mutator methods were also published as named operations (just like in Launchpad 'beta'), but that behavior stopped in 1.0. Call 1.0 the 'cutoff version'.
The 'set_value' method is introduced in 1.0, and it's a normal write operation in 2.0, but in 3.0 it's promoted to a mutator method.
Here's the problem: this method was not available in 1.0 or 2.0. lazr.restful saw that set_value was defined as a mutator, and added a mask registration to stop it from showing up as of the 'cutoff version', 1.0. This would have been the correct behavior if set_value was defined as a mutator *before* the cutoff version, but actually it was defined as a mutator *after* the cutoff version.
lazr.restful was masking the write operation registration in the cutoff version if the method was defined as a mutator in *any* version. This branch changes it so that the operation is only masked in the cutoff version if it was defined as a mutator *before* the cutoff version. If a method is promoted to a mutator after the cutoff version, a lookup for that method will fail starting in the promotion version.
This branch also changes the versioned request marker interfaces in webservice-
FTR:
<danilos> leonardr, I assume there are tests for mutators working correctly otherwise? (since your test only "proves" that it stops providing a method)
<leonardr> danilos: yes, there are. a mutator is just a write operation that doesn't show up in lookups
<leonardr> i could add a test that the mutator works in 3.0
<danilos> leonardr, right, thanks
leonardr, if there are already tests for that elsewhere, no need to imho
leonardr, just one more question: is it still possible to keep a method and make it a mutator? (i.e. have set_value keep working in 3.0)
<leonardr> danilos: no, because there's no point in having a named operation that duplicates the effects of a mutator
<leonardr> the situation we have here is where we made a mistake--this should have been a mutator method all along
but we can't change an old version for backwards compatibility reasons
<danilos> leonardr, well, I can imagine someone wanting to keep both so you don't have to port client code, no?
leonardr, maybe that'd be hidden by things like launchpadlib instead, so I am just wondering
<leonardr> danilos: this falls into the category of 'if you don't want to port code, don't use the new version'
<leonardr> it's an easy change to make
<danilos> leonardr, ok, as long as it's recognized as being a use-case (or not), I think it's fine; some explicit documentation might be useful, if you agree
leonardr, anyway, with that considered, r=me