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.picker...@gmail.com> 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.picker...@gmail.com> 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 <morte...@gmail.com> >> wrote: >> >>> >>> On Thu, Oct 2, 2014 at 8:51 PM, Bob Jolliffe <bobjolli...@gmail.com> >>> 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@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs-core >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> >> -- >> Jason P. Pickering >> email: jason.p.picker...@gmail.com >> tel:+46764147049 >> > > > > -- > Jason P. Pickering > email: jason.p.picker...@gmail.com > tel:+46764147049 >
-- Mailing list: https://launchpad.net/~dhis2-devs-core Post to : dhis2-devs-core@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs-core More help : https://help.launchpad.net/ListHelp