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 <bobjolli...@gmail.com> 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.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 >> > -- 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