On Mon, 29 Mar 2010 17:21:56 +0100, Jonathan Lange <j...@canonical.com> wrote: > I think ultimately you'll need to be explicit. For example, > IBranchTarget(sourcepackage).name != sourcepackage.name for any > ISourcePackage.
Right, that's true, which pretty much rules out the invisible to clients approach, unless a prefix is added. branch_target_name would be ok in my eyes, but branchTargetNewCodeImport() or similar would not be. > There are interfaces which are adapted to that have writeable > properties which change the database when written to. > > Even if there weren't any that existed now, I think it would be > misguided to constrain our object model to make the webservice > implementation easier. Agreed. > > If there are writeable attributes in any adapted objects then you have > > the choice between a PATCH to the object and it's adapted version that > > would have to infer which attributes are associated with which object, > > or two PATCH requests with the inherent atomicity concerns. > > > > I'd lean to the second – to being explicit. The atomicity concerns > would not be unique to adapted objects. True. I think we are in agreement then. There's pretty much nothing that would stop you implementing this approach now, just without any sugar to make it easy to do so. Should I have a look at doing it this way for IBranchTarget.newCodeImport()? Actually, perhaps I don't want to volunteer for that, as I'm not sure how I would implement the canonical url for IBranchTarget, given that it would change based on the target, and IBranchTarget doesn't actually have any attributes for gettting the original object. Thanks, James _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
