Comment 3 for bug 483540

Well, this particular change is possible in principle, but not exactly trivial - I will definitely classify it as a "scope change" instead of a bug fix. We never had this requirement in FluID - we got a confirmation that all "grid" data will have a horizontal dimension linked to EITHER location (e.g. the WPRO form) OR dimension-value coding (e.g. the current H1N1 form), and the code has been tested for those specs.

The root cause is in the way the dimensional data model is constructed (see attached) - LOCATIONS is a parent table for ACTIVITY_MEASUREMENTS (there can be multiple A.M. records for each LOCATION, while each A.M. can belong to one and only one LOCATION). On the other hand, MEASUREMENT_DIMENSION_VALUES is a child table to ACTIVITY_MEASUREMENT (each A.M. record can be linked to multiple M.D.V. values).

That predetermines the logic for processing incoming records ... for LOCATIONS, we just scan each value from the "grid" and perform a simple lookup against LOCATIONS while storing the *whole* ACTIVITY_MEASUREMENTS record; for MEASUREMENT_DIMENSION_VALUES, we have to perform a nested loop in Java to go through the child records and insert/update them one at a time.

To do both (LOCATION and M.D.M.), we will need to add another level of nested loop for child records into the LOCATIONS code handling - and these multiple nested loops are definitely demanding on testing and debugging effort.

With proper testing to avoid any negative impact on existing code and applications, I would estimate this change to approx. 3-5 person-days of effort.