Conversion of calculated data elements to indicators

Support - Assistance technique
1

Dear Devs,

In one of the deployments in Nigeria, we have some 800 calculated data elements. I plan to upgrade this instance soon to either 2.3 or 2.4 (depending on the release schedule). I understand from Lars that the deprecated CDEs are not automatically converted when upgrading. I think it should be possible to convert these CDEs to indicators, but need a bit of advice on untangling the data model in 2.2.

This query

SELECT cde., ex., de.* FROM calculateddataelement cde

INNER JOIN expression ex on cde.expressionid = ex.expressionid

INNER JOIN dataelement de on cde.calculateddataelementid = de.dataelementid

gives me something quite similar to the “indicator” object, of course with some extra columns, but anyway, it will be the basis for creating a series of indicators from CDEs with the “expression” obviously being quite important.

I have a few questions.

  1. I suppose the CDE and indicator syntax is the same/compatible?

  2. What is the purpose of the “expression”, “expressiondataelement” and “expressioncategorycombo” objects? Does it in anyway relate to a CDE or indicator?

  3. Assuming I can come up with a query to insert transformed CDEs into the indicator table, is there any other object I need to be aware of which may not bear a direct relation to the indicator object?

Also, just as an observation the indicatortypeid and numerator both allow NULL fields. I think the denominator attribute can of course be NULL in the case of the new “number” indicator type which have essentially replaced CDEs, but I am not sure that it makes sense to allow NULL in the above mentioned fields. I know this is probably enforced through the UI, but it may be a change to consider for the model.

Thanks and best regards,

Jason

2

Hi Jason

1) I suppose the CDE and indicator syntax is the same/compatible?

Yes. The CDE expressions are a bit verbose but perfectly legal.

2) What is the purpose of the "expression", "expressiondataelement" and
"expressioncategorycombo" objects? Does it in anyway relate to a CDE or
indicator?

Purpose is to maintain relational integrity for the data elements and
category option combos used in the expression. Eg if a data element is
deleted then there must be a way to update all expressions to maintain
validity. Indicators are not using expressions however, just CDE and
validation rules.

3) Assuming I can come up with a query to insert transformed CDEs into the
indicator table, is there any other object I need to be aware of which may
not bear a direct relation to the indicator object?

Not any I can think of.

Also, just as an observation the indicatortypeid and numerator both allow
NULL fields. I think the denominator attribute can of course be NULL in the
case of the new "number" indicator type which have essentially replaced
CDEs, but I am not sure that it makes sense to allow NULL in the above
mentioned fields. I know this is probably enforced through the UI, but it
may be a change to consider for the model.
Thanks and best regards,
Jason

Yes you are right here, we need to go through the whole schema and
check that it is in sync with GUI.

Lars