dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 15 October 2013 14:34, Lars Helge Øverland <larshelge@xxxxxxxxx> wrote:

> 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.
>

Yes that is correct.  We are not really linking the object model fully
through the hibernate layer (which would imply cascading and the like).  So
the timestamp on the orgunit table relates only to those properties of the
orgunit which are stored in the table.  So what we call the orgunit
"object" in terms of persistence is a little fuzzy.


>
> 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.
>

Ah I was worried this might be the case. (I thought we used a version
object?).

Short term, since I have no option currently except getting down and dirty
in the sql to workaround, I guess I should instead create a new table for
updated orgunit ids, but whose update stamp takes into account groups,
attributes and what have you.  And leave the orgUnit lastUpdated untouched.

There might be a secondary benefit of having a separate table for logging
orgunit updates via trigger .. I could possibly also record the deletions
which is currently another missing functionality in the picture.  Hopefully
will get time to look more at this tomorrow.

Cheers
Bob



>
> 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
>>
>>
>