dhis2-devs-core team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

The intended client I am looking to ensure which is working is DHIS2
itself. We do not "transmit" deletes, which of course we could, but right
now, we do not nor have a clean way to handle them. So for clients which
transmit zeros, DHIS2 needs a way to handle them, based on its settings.
Perhaps some DHIS2 instances will want the zeros, while others will not,
but the important thing is, if a non-zero exists and the data element is
non-zero significant, and zero is received as an update, then the existing
non-zero value should be deleted. I think supporting the DELETE is a good
idea, but for "dumb" clients, they may simply attempt to import some CSV
data, and DHIS2 should handle it accordingly.

Regards,
Jason


On Fri, Oct 3, 2014 at 6:13 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> That behaviour sounds right to me.
>
> Though it is something of a special case to delete zeros because we don't
> store them.
>
> I am less convinced by the general case. I would prefer to use http delete
> method and disregard value (if present). Still not sure what a null value
> is in dxf anyway. But the method suggested feels more like a non intuitive
> side effect than a very deliberate action.
> On 3 Oct 2014 14:48, "Jason Pickering" <jason.p.pickering@xxxxxxxxx>
> wrote:
>
>> Oops, let me try again..
>>
>> I could not make this call, but wanted to bring up a few points on this
>>
>> https://blueprints.launchpad.net/dhis2/+spec/delete-on-import-null-value
>>
>> Another important scenario here is when data values ARE zero significant
>> in a downstream system, but in DHIS2, a value already exists which is
>> non-zero and the data element is zero insignificant. The downstream system
>> may have no idea about how DHIS2 handles zeros, and therefore, may transmit
>> a zero as opposed to a NULL. The desired behaviour then would be that if
>> the data element is zero-insignificant, a value already exists, and the
>> update value is zero, then the existing value in upstream system should be
>> deleted. This is described in more detail here (
>> https://bugs.launchpad.net/dhis2/+bug/1355232).
>>
>> Regards,
>> Jason
>>
>>
>> On Fri, Oct 3, 2014 at 3:44 PM, Jason Pickering <
>> jason.p.pickering@xxxxxxxxx> wrote:
>>
>>> I could not make this call, but wanted to bring up a few points on this
>>>
>>>
>>> On Fri, Oct 3, 2014 at 3:32 PM, Morten Olav Hansen <mortenoh@xxxxxxxxx>
>>> wrote:
>>>
>>>>
>>>> On Thu, Oct 2, 2014 at 8:51 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>>> wrote:
>>>>
>>>>> https://blueprints.launchpad.net/dhis2/+spec/web-api-error-messages
>>>>>
>>>>
>>>> I saw your comment Bob, and yes, we will be watching the accept header
>>>> (this was mentioned in call just before you joined ;-)). I'm not sure how
>>>> much I will be able to get in for 2.17, but at least I should be able to
>>>> define the model, and provide more robust feedback in
>>>> AbstractCrudController, and then we can extend on that for 2.18.
>>>>
>>>> I'm also planing to keep all web-api messages in i18n files, so that we
>>>> can also translate on output (if available). We should also introduce coded
>>>> error/info messages, so that its easier for the third party client to know
>>>> what is happening, returning conflict and a message is not really enough.
>>>>
>>>> --
>>>> Morten
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~dhis2-devs-core
>>>> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dhis2-devs-core
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>>
>>> --
>>> Jason P. Pickering
>>> email: jason.p.pickering@xxxxxxxxx
>>> tel:+46764147049
>>>
>>
>>
>>
>> --
>> Jason P. Pickering
>> email: jason.p.pickering@xxxxxxxxx
>> tel:+46764147049
>>
>


-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+46764147049