dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Here's a clarifying example.  In a facility-centric view of orgunits, their
coded properties are part of the orgunit rather than some disconnected
group concept.  So a simple FRED example would look like:

{
    "name": "Nyanza DH",
    "coordinates": [
        29.7493,
        -2.3526
    ],
    "active": true,
    "properties": {
        "Fosaid": "49",
        "Dhis2UID": "a7LjsllVnD4",
        "ownership": "Public",
        "Type": "DH"
    },
}

Now I have this data in dhis2 (amongst the orgunit and related groups
tables) but no way of knowing whether one of the last two properties has
been updated.

Anyway I'll solve it in sql and we can consider what the longer term
solution should be.  Maybe an additional uberLastUpdated column on the
orgunit table :-)

Bob


On 15 October 2013 16:38, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> I don't think so.  If there are 1000 orgunits in a group and one changes I
> don't really have a way of knowing which one changed.  So I would have to
> update all orgunuts in that group.
>
> If it is dhis2dhis then just resynching the group would work.  But most
> systems with coded properties, like 'type', 'ownership' don't use the same
> groups idea.
>
> What I need is some indication of when an orgunit object (including its
> attributes and group memberships have changed).  This is a blind spot in
> our api currently.
>
>
> On 15 October 2013 16:18, Lars Helge Øverland <larshelge@xxxxxxxxx> wrote:
>
>>
>>
>>
>>> 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.
>>>
>>>
>> Okay. Could another temporary work-around be to just check for recent
>> updates of org unit groups through the web api?
>>
>>
>>
>