Hi Morten Thanks for the information.
Regarding the filtering bug, do you know which version/build this was fixed in? I am still seeing the issue in 2.20-SNAPSHOT build #19473 Kind regards Alan On Tue, Jul 7, 2015 at 9:35 PM, Morten Olav Hansen <morte...@gmail.com> wrote: > Hi > > Most of this should now be fixed, please note that also our import > summary(ies) are now wrapped in a WebMessage (check responseType to know > which payload was sent) > > Regarding the filtering bug, that was fixed a while back. > > We know about the difference in paging parameters, but we will not change > it right now. I think you should be ok if you follow this simple rule 1) if > its metadata use paging=true/false 2) if its data use skipPaging=true/false > > Thanks for reporting the issues. > > -- > Morten > > On Fri, Jun 19, 2015 at 3:56 AM, Alan Hill <ah...@2paths.com> wrote: > >> Hi >> >> I have a couple of additions: >> >> - Filtering results does not always retrieve the record you're after >> unless you specify paging=false (or it's on the first page) >> - Some entties use paging=false, others use skipPaging=true >> >> Thanks >> >> Alan >> >> >> On Thu, Jun 18, 2015 at 1:07 PM, Lorill Crees <lcr...@2paths.com> wrote: >> >>> Hi Morten, >>> >>> These are the places where we're seeing inconsistencies: >>> >>> - /api/sqlViews/<id>/execute POST: returns String - "SQL view >>> created" >>> - /api/sqlViews/<id>/data GET: exception in tomcat logs returns HTML >>> error page (eg: if view has not been executed) >>> - >>> - /api/events POST: returns importSummaries in JSON (inconsistent >>> with other api calls where importCount, importConflicts, conflicts etc >>> are >>> at root level) >>> - /api/events PUT: returns String - "Event updated...." >>> - /api/trackedEntityIntances POST: returns 'reference', not >>> 'lastImported' in JSON >>> - /api/trackedEntityInstances POST: exception in tomcat logs returns >>> HTML error page >>> - There are also many api calls for assignments i.e. >>> - /api/<entity>/<id>/<entity>/<id> >>> That return 204 (no body). Is this intentional/expected >>> behaviour? >>> >>> Thanks, >>> >>> Lorill >>> >>> On Wed, Jun 17, 2015 at 6:34 PM, Morten Olav Hansen <morte...@gmail.com> >>> wrote: >>> >>>> Hi >>>> >>>> We have started changing some of endpoints already, if you e.g. try to >>>> get a invalid data-element /api/dataElements/abc123 you will see the new >>>> output format (xml and json supported, json is default). I have not started >>>> changing the import conflict format yet, and it probably will not be >>>> changed for 2.20, I'm hoping to start a rewrite of the importer in 2.21, >>>> and the change of response format would then end up being in that release. >>>> >>>> Besides the import conflicts, if you are still seeing plain text error >>>> messages anywhere, please report back to me and I will replace them with a >>>> proper message. >>>> >>>> -- >>>> Morten >>>> >>>> On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees <lcr...@2paths.com> >>>> wrote: >>>> >>>>> Thanks Morten. >>>>> >>>>> On a related note, have you defined how you will be changing the >>>>> response messages yet? We've written a rudimentary response message parser >>>>> as part of our app because we get quite inconsistent results from the >>>>> various web api calls. EG: some responses return "conflicts" whereas >>>>> others >>>>> return "importConflicts". Also we consistently ask for the response in >>>>> JSON >>>>> yet some responses return HTML regardless which makes parsing the >>>>> responses >>>>> difficult. >>>>> >>>>> Knowing the changes you have planned will be helpful as it could >>>>> potentially break the way we're currently parsing the results. >>>>> >>>>> By the way, we're working off 2.20 snapshot. >>>>> >>>>> Thanks, >>>>> >>>>> Lorill >>>>> >>>>> >>>>> >>>>> On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen < >>>>> morte...@gmail.com> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> No, this is not currently supported. We might support it in a future >>>>>> release, as we are changing our responses messages a bit in 2.20/2.21. >>>>>> >>>>>> -- >>>>>> Morten >>>>>> >>>>>> On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees <lcr...@2paths.com> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Is it possible to receive messages back from the web api in other >>>>>>> languages? Specifically if there are import conflicts we would like to >>>>>>> give >>>>>>> these messages back to the user in their preferred language. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Lorill >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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
