Closed zzgvh closed 6 years ago
Investigation around enforcing numeric values
Currently we don't store any computed values on the indicator level
The following fields should be made numeric:
The fields are used in the following places. Refactoring needed is indicated with bold face
not self.actual_value
The following fields should be made numeric:
How about numerical values using decimal commas?
Closed in #3076
We should not allow non-numerical values for indicators that aren't qualitative. I'm copying what I wrote in #2756 here:
With the introduction of qualitative indicators I would recommend that we enforce numerical values only for quantitative updates.
To see if this would be hard, I checked how many updates we currently have that would need "fixing", i.e. they are updates with non-numerical values. The results look like this
using this SQL:
(The SQL can be easily modded to show which projects, results etc the updates belong to)
The Value column is the text entered as data for the update, the Count column is how many updates have this exact value. Note that the first value is an empty string, and the second is only a hyphen, "-", but markdown mess them up 😉. The results above suggest that it should be easy to migrate the values since most of them are an indication that there is no value. The few that hold any data can be moved to the text field for the update.
To see which projects and organisations that have non-numerical values in current indicator updates I ran this SQL:
Resulting in the following list (Note that there are more records here than above since more than one organisation may be connected to a project and thus to a particular data value.):
We need to figure out how to migrate the non-numerical values that currently are in the DB. Most of them seem like "non values" but I think we need to check with the partner team what the values signify to understand how to go about this migration.