This is for updatePersonAppData not fetchAppData. Update says: newUpdatePersonAppDataRequest
Object *newUpdatePersonAppDataRequest*(id, key, value) Creates an item to request an update of an app field for the given person. When processed, does not return any data. *Parameters:* *String* id - The ID of the person to update; only the special VIEWER ID is currently allowed. So the id must be a string - and in 0.7 it can only be VIEWER. - Cassie On Tue, Sep 2, 2008 at 12:09 PM, Shreyas Desai (શ્રેયસ દેસાઇ) < [EMAIL PROTECTED]> wrote: > 0.7 spec says it does expect idSpec. > > http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.html#newFetchPersonAppDataRequest > > > > On Tue, Sep 2, 2008 at 11:28 AM, Cassie <[EMAIL PROTECTED]> wrote: > > This is happening because of this test: > > > > name: 'newFetchPersonAppDataRequest - OWNER_FRIENDS, \'*\')', > > id: 'APP007', > > ... > > req.add(req.newUpdatePersonAppDataRequest( > > opensocial.DataRequest.Group.OWNER_FRIENDS, 'PDRT008_K1', > > this.data.personalValue), 'k1Update'); > > > > > > newUpdatePersonAppDataRequest accepts an id string (not an idspec) so the > > constant "OWNER_FRIENDS" is treated as a generic user id. The test should > > not be calling this method as OWNER_FRIENDS is not considered a valid id > > (unlike VIEWER and OWNER - which are valid ids). > > > > - Cassie > > > > > > > > On Tue, Sep 2, 2008 at 10:18 AM, Louis Ryan <[EMAIL PROTECTED]> wrote: > >> > >> This is definitely not a valid URL, > >> > >> /appdata/@owner/@friends/@app > >> > >> is the right URL to get "the appdata for the owners friends for the app > >> defined in the associated security token" > >> > >> On Thu, Aug 28, 2008 at 4:57 AM, Chris Chabot <[EMAIL PROTECTED]> > wrote: > >> > >> > While running the reference test suite I'm seeing a number of requests > >> > fail > >> > on URLs in the batch request like: > >> > /appdata/OWNER_FRIENDS/@self/@app > >> > > >> > Now you may color me silly, but i really would've expected something > >> > along > >> > the lines of: > >> > /appdata/@owner/@friends/@app > >> > > >> > I haven't had the time yet (I seem to have way to little of that these > >> > days) to diagnose if it's an invalid request from the test suite, or > if > >> > it's > >> > the (legacy) rest-rpc code, but as far as i can tell, that shouldn't > be > >> > able > >> > to happen :) > >> > > >> > Oh ps, it seems it's going wrong on the POST only, GET's work as > >> > intended > >> > (see batch blob below) > >> > > >> > Anyone have any ideas what could be causing that? > >> > > >> > Full batch request from the test suite (incase it helps to map it > >> > against > >> > the test #): > >> > > >> > > >> > > >> > > {"k1Update":{"url":"/appdata/OWNER_FRIENDS/@self/@app?fields=PDRT008_K1","method":"POST","postData": > >> > {"PDRT008_K1":"personalValue > >> > > >> > > 1219923727663"}},"k2Update":{"url":"/appdata/OWNER_FRIENDS/@self/@app?fields > >> > =PDRT008_K2","method":"POST","postData":{"PDRT008_K2":"personalValue > >> > 1219923727663"}},"per":{"url":" > >> > /appdata/@owner/@friends/@app?networkDistance=&","method":"GET"}} > >> > > >> > > >> > > > > > >
