Invoke a named operation on a collection, and the collection is fetched.

This is actually because it has to GET the first page of lp.branches first before
we can call the method, so it's not entirely client side.

Thanks,

James

It shouldn't be GETting the first page of lp.branches: you should get a shim object that doesn't make that GET request unless you do something like iterate over the branches.

I think we can fix this by changing launchpadlib to be aware of the new top-level collection. I also think this points to a general flaw in launchpadlib's otherwise-excellent "You don't have to change the client when the server changes" design.

On Thu, 22 Apr 2010 15:26:38 -0000, Leonard Richardson <email address hidden> wrote:
> It shouldn't be GETting the first page of lp.branches: you should get a
> shim object that doesn't make that GET request unless you do something
> like iterate over the branches.

I've just actually verified my assertions and it is in fact making *two*
GET requests to /1.0/branches before building the NamedOperation
request.

Thanks,

James

OK, this isn't so bad. When looking up "getByUniqueName", lazr.restfulclient's Resource.__getattr__ calls lp_get_parameter (which requires a representation) and when that lookup fails it calls lp_get_named_operation. Simply calling lp_get_named_operation first solves the problem.

It does mean that if there is a field called 'getByUniqueName', the named operation will take precedence over the field, but that's not really any worse than the field taking precedence over the named operation--that whole situation should be avoided.

Once I figure out how to test this I'll do a branch and a release.

The single request that the web service spends the most time processing is "GET /branches". I'll warrant almost all of those hits come from scripts that invoke a named operation on the top-level collection. This branch will have a big impact on performance, in a "stop hitting yourself with a hammer" sense.

I ran a test on this and it turns out that there's still one request to /branches. That's better than two, but I don't know where the other one is coming from.

Actually, never mind. I was running a test against the old lazr.restfulclient and I saw one request to /branches, which is what I've always seen. When I run a test against the new lazr.restfulclient I see zero requests to /branches. James, I'd like you to try the new lazr.restfulclient and see whether you see one request to /branches or none at all. If you're still seeing one request, I'd like to see the full script you're running so I can try and duplicate.