On Wed, Jun 11, 2014 at 12:03 PM, Kiran Prakash <kprak...@thoughtworks.com> wrote:
> Is it possible to keep backward compatibility intact while making API > changes? > Ideally yes, but these changes did require breaking the API in a few places. Going forward there should be no major changes to the external API (only additions). One more place where the API change is breaking our code is this, while > querying the org hierarchy. > > for eg: > http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true > Yes, this have been disabled for now, should be back very soon (today) together with includeChildren. -- Morten Would give the queried organization and all its descendents and its custom > attributes etc. > > with the new API, we're trying to get > > <http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all]> > > http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all] > > the decendents of the org has been renamed to 'children', but the > children does not have all the custom attributes set. We are using a custom > attribute on the organization to figure the type of node in the hierarchy > (eg. country, hospital, etc ) and some of our domain logic is based on this > type. > > > Are we missing something in our query? Please let us know. > > Thanks in advance, > > Kiran. > > > > On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen <morte...@gmail.com> > wrote: > >> Yes, >> >> This is by design, :all merely means "give me all property on current >> level". It will by default render idObjects with just idObject properties, >> and Collections of idObject as a collection of idObject properties. >> >> I know this breaks things, but we were really not happy with the current >> use of viewClasses (@JsonView), I hope it won't be too difficult to >> implement. >> >> We do support recursive expansion of the fields properties, so you can do >> ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes.. this requires changes to >> your code (most of this is supported in 2.15, but you will to use include= >> instead) >> >> -- >> Morten >> >> >> On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan < >> aravi...@thoughtworks.com> wrote: >> >>> Hello Morten, >>> >>> Thank you for the quick fix! >>> >>> We were trying the new api and it works. We also looked at the code a >>> little bit, and we saw that if we don't give any query params, we are >>> defaulting it to ":all". However this retrieves fields only at the first >>> level and does not retrieve fields for the nested entities. >>> >>> Ex: When we get user object using say */api/users/OYLGMiazHtW.json *it >>> just gets the user object and does not get all the fields of the >>> userCredentials object. >>> >>> This might break backwards compatibility of the api, as the older api >>> was giving out all the fields by default including nested objects. Is this >>> the expected behaviour? >>> >>> >>> Thanks, >>> Aravind >>> >>> >>> On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen <morte...@gmail.com> >>> wrote: >>> >>>> Hi >>>> >>>> This should now be working in rev 15615. >>>> /api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all] >>>> >>>> Please try it out and report any issues back >>>> >>>> -- >>>> Morten >>>> >>>> >>>> On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen <morte...@gmail.com >>>> > wrote: >>>> >>>>> Hi >>>>> >>>>> All our endpoint have now been switched our to using the new field >>>>> filtering (similar to the old inclusion/exclusion), so the data you want >>>>> is >>>>> probably there, but you have to tell the system you want to have it. I do >>>>> see that there is a bug in the UserCredentials class, I will fix that >>>>> tomorrow. >>>>> >>>>> Please see the documentation here: >>>>> http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html >>>>> >>>>> Regarding the the custom serializers, we needed a bit more custom >>>>> control over the output, we still use Jackson (ObjectMapper, but not >>>>> data-binding) in the backend, together with xml (StAX). >>>>> >>>>> -- >>>>> Morten >>>>> >>>>> >>>>> On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya < >>>>> mahen...@thoughtworks.com> wrote: >>>>> >>>>>> Hello Morten, >>>>>> >>>>>> We're facing some issues due to some recent changes to UserController. >>>>>> >>>>>> The serialized 'User' json has some issues. >>>>>> >>>>>> The 'usercredentials' field is now being serialized as >>>>>> 'org.hisp.dhis.user.UserCredentials' and also some of the properties of >>>>>> UserCredentials (like userAuthorityGroup ) is not being serialized. >>>>>> >>>>>> One of our application is breaking due to these contract changes. We >>>>>> tried fixing it, but soon got lost in the custom serialization code. >>>>>> >>>>>> Can you please have a look at this. >>>>>> >>>>>> ( Also on a side note, is there any specific reason we are going for >>>>>> custom serialization instead of going for standard serializers like >>>>>> Jackson? ) >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Mahendra/Kiran >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dhis2-devs >>> Post to : dhis2-devs@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : dhis2-devs@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
