Hm, ok.. no we don't currently support that. As a workaround, you could of course just do ?fields=:all,children[:all,children[:all]], i.e. :all,children[:all] for as many levels as you have, its a bit of a hack, but it would work (if you add too many, it will just be ignored)
If its only two, you could also just have two requests /api/organisationUnits/ID1?includeDescendants=true /api/organisationUnits/ID2?includeDescendants=true It might be quicker in your case if the amount of OUs is that not that (this is not ideal obviously). I could extend the controller to add support for includeChildren/descendants after our main filters are run, but I don't think that will help you right now, since you are running an older version of trunk anyways, right? -- Morten On Fri, Sep 5, 2014 at 12:31 PM, Mahendra Kariya < [email protected]> wrote: > We need full view of few OUs along with full view of their descendants > along with full view of descendants' descendants and so on. > > I tried the following URL, but it doesn't help. > > http://localhost:8080/api/organisationUnits.json?fields=[:all,children[:all]]&filter=id:eq:a42405657c4&filter=id:eq:ade053ef050&paging=false > > > > > On Fri, Sep 5, 2014 at 10:55 AM, Morten Olav Hansen <[email protected]> > wrote: > >> You mean children, or descendants? if you just want the full view of the >> children of a few OUs you could probably get away with >> >> ?fields[:all,children[:all]] ? >> >> -- >> Morten >> >> >> On Fri, Sep 5, 2014 at 12:18 PM, Mahendra Kariya < >> [email protected]> wrote: >> >>> OK. >>> >>> So we need all fields for an org unit, but we don't need all org units. >>> We only need a few org units with all fields and all its children >>> (recursively). >>> >>> I tried GETting this information with the URL >>> http://localhost:8080/api/organisationUnits.json?fields=[:all]&includeChildren=true&filter=id:eq:a42405657c4&filter=id:eq:ade053ef050&paging=false >>> >>> >>> But the response doesn't have all children recursively. Can we use >>> includeChildren=true param on /api/organisationUnits or it only works on >>> /api/organisationUnits/{id}? If this param is not supported on >>> /api/organisationUnits, is there some other work around? >>> >>> >>> >>> >>> On Fri, Sep 5, 2014 at 10:42 AM, Morten Olav Hansen <[email protected]> >>> wrote: >>> >>>> >>>> On Fri, Sep 5, 2014 at 11:55 AM, Mahendra Kariya < >>>> [email protected]> wrote: >>>> >>>>> It looks like attributeValues field takes most of the time. We have >>>>> around 6-7 custom attributes for each orgUnit. We don't need all of these. >>>>> We only need the value of one particular attribute. Is there a way to do >>>>> this? >>>>> >>>> >>>> Hm, no. We only allow filtering for a specific value, but I guess you >>>> don't really know the values here. Its more difficult to filter inside a >>>> collection, not sure how the API would look for that. >>>> >>>> We might want to support something like that in the future, but its >>>> definitely not supported today. >>>> >>>> The best solution here would be to use http gzip if you don't already >>>> use it. You could also get the data from >>>> /api/metadata.gz?assumeTrue=false&organisationUnits=true but that probably >>>> won't work as expected in a browser setting, unless you use some kind of JS >>>> gunzip. >>>> >>>> -- >>>> Morten >>>> >>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
