dhis2-devs team mailing list archive

[Alan Hill <ahill@xxxxxxxxxx>]

Hi Morten....apologies for the delay in replying.

I am still seeing this with

    /api/trackedEntityAttributes

2.20-SNAPSHOT
Build revision: 19647

I will let you know if I encounter any others.

Regards

Alan

On Wed, Jul 8, 2015 at 11:06 PM, Morten Olav Hansen <mortenoh@xxxxxxxxx>
wrote:

> Hi
>
> In which endpoints do you see this? I have fixed it in the data element
> operand endpoint, but there could be others also
>
> --
> Morten
>
> On Thu, Jul 9, 2015 at 12:23 AM, Alan Hill <ahill@xxxxxxxxxx> wrote:
>
>> 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 <mortenoh@xxxxxxxxx>
>> 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 <ahill@xxxxxxxxxx> 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 <lcrees@xxxxxxxxxx>
>>>> 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 <
>>>>> mortenoh@xxxxxxxxx> 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 <lcrees@xxxxxxxxxx>
>>>>>> 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 <
>>>>>>> mortenoh@xxxxxxxxx> 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 <lcrees@xxxxxxxxxx>
>>>>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>