dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

Hi Bob,

you are right. The technical explanation is that we update the timestamp in
the service layer whenever the org unit (applies to all kind of objects) is
explicitly updated - not when associations are updated on the other end.

I guess the problem is that some use-cases require different behavior here
- for example we use the timestamps to control when the org unit tree must
be re-downloaded to the client/browser after changes and here we do not
want to force an update when only group associations are changed.

So maybe we need to introduce more timestamp properties to handle this
ideally. Not sure.

Lars



On Mon, Oct 14, 2013 at 6:41 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> orgunits effectively have coded parameters, for example Type and Ownership.
>
> A problem is that if these are changed (eg. change type to 'Health
> Centre'), there is no simple way to know whether this orgunit has been
> updated or not.  This is important if you want to relay changes from the
> dhis server to another system.  And presumably affects our FRED
> implementation.
>
> Attached workaround uses an sql trigger to force an orgunit timestamp when
> any of its group memberships change.  This is obviously postgres specific
> and would need to be translated for the likes of mysql.
>
> This works like a charm, but is it the desired behaviour?  Depends really
> on how we choose to interpret lastUpdated.  If it is, should we consider
> dhis taking care of this itself.
>
> If this is the wrong approach can anyone suggest another?
>
> Bob
>
> _______________________________________________
> 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
>
>