Merge lp://staging/~leonardr/lazr.restfulclient/server-takes-precedence into lp://staging/lazr.restfulclient
| Status: | Merged |
|---|---|
| Approved by: | Aaron Bentley |
| Approved revision: | 104 |
| Merged at revision: | 101 |
| Proposed branch: | lp://staging/~leonardr/lazr.restfulclient/server-takes-precedence |
| Merge into: | lp://staging/lazr.restfulclient |
| Diff against target: |
153 lines (+106/-6) 4 files modified
src/lazr/restfulclient/NEWS.txt (+13/-4) src/lazr/restfulclient/docs/toplevel.txt (+80/-0) src/lazr/restfulclient/resource.py (+12/-1) src/lazr/restfulclient/version.txt (+1/-1) |
| To merge this branch: | bzr merge lp://staging/~leonardr/lazr.restfulclient/server-takes-precedence |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Aaron Bentley (community) | Approve | ||
| Gary Poster | Pending | ||
|
Review via email:
|
|||
Description of the change
Let's say you have a shim object of resource type 'foo'. Because it's a shim, you don't have any real data for it, but you can get some data by accessing one of the many properties of a 'foo'-type object. When you do this, lazr.restful makes a request for the corresponding resource.
But, uh-oh! When lazr.restful makes the request, the representation of this resource says it's not a 'foo' object at all! It's actually a 'bar' object! What to do?
Currently, lazr.restful stubbornly insists that the object is a 'foo' object, and you can only access the features that are common to 'foo' and 'bar'. This branch changes things so that once the representation is received, the resource silently changes into a 'bar' object. You'll only get an error if you tried to access a feature of 'foo' that wasn't in 'bar'.
This is important for my upcoming launchpadlib branch, where 'foo' == 'team' and 'bar' == 'person'.
I have reservations about letting objects change type, but leonardr has convinced me that this is not a practical problem. The discrepancy would be hard to provoke, because accessing members will cause the object to be loaded.
I would like to see mention in the documentation that WADL doesn't allow inheritance relationships to be explored. Otherwise, this is fine.