dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Hi Jose,
I do not understand exactly what you are trying to do. It sounds a bit
tricky, but if I understand correctly, you would like to somehow preserve
the original state of your indicator, in spite of the fact that you may
want to change it at a later point in time. I think this is particularly
difficult to do. Creating a table of inserted values is fairly simple using
a function similar to the one below. This SP will insert records into a
separate table called "pricate.completeddatasetregistration_new_records,
whenever a record is inserted into the "completeddatasetregistration"
table. This is a pretty typical approach to create an audit table. I am
guessing that you could create an audit table of your indicators, and then
create a separate function to prune out all values except the first one
(which would know through a time stamp). However, the problem with this
approach is, you may not really know if this value is the "final" value or
not; the data might change, and in this case, the indicator value would
need to change (but not because of a change to the indicator formula).

Sounds pretty complex to me. How do you know when the value is finalized
and will never be changed again?

Regards,
Jason


SQL below..

Here is the SP which inserts the records into another table.

CREATE OR REPLACE FUNCTION completedatasetregistration_new()
  RETURNS trigger AS
$BODY$
DECLARE
 changed boolean;
BEGIN

   INSERT INTO private.completedatasetregistration_new_records(datasetid,
periodid,sourceid,
date, storedby)
   VALUES (new.datasetid, new.periodid,new.sourceid,
now(),new.storedby);
   RETURN new;

END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION completedatasetregistration_new()
  OWNER TO postgres;

Here is the trigger function  attached to the
"completeddatasetregistration" table...only after an insert.


CREATE TRIGGER inserts_completedatasetregistration
  AFTER INSERT
  ON completedatasetregistration
  FOR EACH ROW
  EXECUTE PROCEDURE completedatasetregistration_new();


On Sun, Jul 14, 2013 at 8:40 PM, Jose Garcia Muñoz <josemp10@xxxxxxxxx>wrote:

>
> Thanks Bob!
>
> You are right in the sense that the indicator becomes redundant, but I
> think we will still need it because we can train the end-users in the use
> of formulas and indicators inside DHIS2, but stored procedures is quite
> hard if they don't have much technical skills. So the idea I think is to
> define a function in plpgsql to make a copy of the value of the indicator
> into the dataelement (knowing the period and source of course) linking the
> function to a trigger. Please correct me if I am wrong, as I don't have
> much experience using triggers.
>
> Also, when you introduce an indicator into a dataset, when does the
> indicator update its value? (when you click in the complete button of the
> dataentry maybe?) and which table stores the value of the indicator?
> (attributevalue?)
>
> Thanks
> Jose
>
>
> On Sun, Jul 14, 2013 at 12:40 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>wrote:
>
>> Hi Jose
>>
>> Copying to devs list as there may be greater wisdom there :-)
>>
>> I think your approach can work .. ie store your historical scores as
>> dataelement.
>>
>> Regarding regenerating the formula, again I think you are right and will
>> have to resort to a database function as I can't think of an easy
>> workaround through the application and you really don't want to do these
>> manually.
>>
>> Though I start to think that if you go down this route perhaps the
>> indicator becomes redundant.  You will have your formula as stored proc in
>> database and can probably use that to populate your "score" dataelement
>> directly.
>>
>> Bob
>>
>>
>> On 14 July 2013 12:15, Jose Garcia Muñoz <josemp10@xxxxxxxxx> wrote:
>>
>>>
>>> Hi guys,
>>>
>>> How are you doing?
>>>
>>> first at all, maybe I should send this email to the dev user list, if
>>> so, sorry about that and please feel free to resend it.
>>>
>>> I am dealing with several forms in DHIS2 with all its DE of the
>>> "trueOnly" type value. For each form, one final score is calculated
>>> depending on the number of questions answered by the users and one weight
>>> associated for each question. Of course, we have defined an indicator to
>>> calculate this value. But, what about when the number of questions (or the
>>> different weights) change along the time (so the formula needs to be
>>> redefined) and we still need to maintain the historical score of the "old"
>>> formulas?
>>>
>>> We were thinking about the possibility of creating a data element for
>>> each form to store the historical scores. Does it make sense? If so, the
>>> big challenge will be the connection of the indicator (when its value is
>>> calculated) with the Data Element. Some ideas about how could I deal with
>>> this? Create a trigger inside the database (with an 'on completion' event)?
>>>
>>> Best regards
>>> Jose
>>>
>>
>>
>
> _______________________________________________
> 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
>
>