dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

Okay I see u have a point. We could maybe make it a bit more intelligent and
check on the client side whether we are dealing with an update going from
non-zero to zero for a zero-insignificant data element, and in those cases
only send a request to server for removal of that value.

2011/2/15 jason.p.pickering <717761@xxxxxxxxxxxxxxxxxx>

> OK maybe, but I think you are missing a critical point.   I do not
> think it is feasible to enforce this sort of rule on users which you
> describe. Lets suppose  a user would enter a (1) for example, only to
> notice that in fact it is zero on their data entry form. They then
> re-enter a zero, only to have the system not  delete the existing
> value in the database, leading to a data entry error, which is not
> entirely their fault. Meaning they would need to 1) delete the value
> (resulting in a round trip to the DB in all cases) and reenter a zero
> (which may or may not result in a round-trip depending on the
> zero-significant setting). This would result in two round trips
> instead of just one.   They would have to know from the beginning
> which DEs are zero-significant and which values are not significant,
> and know whether to delete the value entirely before they attempt to
> enter a zero. With data elements ranging in the thousands (or at least
> hundreds) there is no way they can possibly know whether to delete the
> value, or actually enter a zero. Or, perhaps I still do not understand
> how this actually works?
>
> On 2/15/11, Lars Helge Øverland <larshelge@xxxxxxxxx> wrote:
> > No I am not mixing it up. First of all there is a deliberate decision not
> to
> > send zero values to the server due to performance considerations. Data
> entry
> > causes the biggest load on the server and zeros typically constitutes 75%
> of
> > the data - hence we reduce the load on the server correspondingly.
> Checking
> > for what you suggest will require a trip to the server and we loose this
> > benefit.
> >
> > Second, the rule now is simple - zero values are saved if significant and
> > ignored if not. An exception for saying that 0 should delete existing
> values
> > are not natural and more confusing. I agree that this stuff is not
> perfect
> > but we are making a trade-off here.
> >
> > Finally, Tri, this behavior is quite crucial and it is not OK to commit
> > changes without discussing with me, as I have explained 100 times.
> >
> > --
> > You received this bug notification because you are a member of DHIS 2
> > India Developers, which is subscribed to DHIS.
> > https://bugs.launchpad.net/bugs/717761
> >
> > Title:
> >   0 value doesn't delete existing data
> >
> > Status in DHIS 2 - District Health Information Software:
> >   Fix Committed
> >
> > Bug description:
> >   When entering 0 in a data entry field where a data value already is
> >   entered, the box turns green, indicating that the value is stored. But
> >   when "re-visiting" the form the old value is still there. The data
> >   entry field should be empty!
> >
> >
> >
>
>
> --
> Jason P. Pickering
> email: jason.p.pickering@xxxxxxxxx
> tel:+260974901293
>
> --
> You received this bug notification because you are a member of DHIS 2
> coordinators, which is the registrant for DHIS.
> https://bugs.launchpad.net/bugs/717761
>
> Title:
>  0 value doesn't delete existing data
>
> Status in DHIS 2 - District Health Information Software:
>  Fix Committed
>
> Bug description:
>  When entering 0 in a data entry field where a data value already is
>  entered, the box turns green, indicating that the value is stored. But
>  when "re-visiting" the form the old value is still there. The data
>  entry field should be empty!
>
>
>

-- 
You received this bug notification because you are a member of DHIS 2
developers, which is subscribed to DHIS.
https://bugs.launchpad.net/bugs/717761

Title:
  0 value doesn't delete existing data

Status in DHIS 2 - District Health Information Software:
  Invalid

Bug description:
  When entering 0 in a data entry field where a data value already is
  entered, the box turns green, indicating that the value is stored. But
  when "re-visiting" the form the old value is still there. The data
  entry field should be empty!