grid does not support locations and dimensions at the same time

[Said Bouzenzana@B.I.]

Dear Jiri ,
I’m working on location data persistence and I’m facing an issue .
Let’s take following example .
We want to submit ,for different locations, data for 2 measures sharing same dimensions .
What I’m experiencing is that case is not supported by the module <<data line loader>> I get error message : Grid does not support dim and location at the same time ..
At the beginning at thought only bypassing this check so that to say comment the line which tests and throws the exception if grid has dims and location .
But looking deeper at the code we will need to change this one and this will be in depth impacting the behavior of your requirements.

My question is :
Would you plan a change for this in order to extend this functionality (enabling grid to have dims and locations) or shall we deal with the locations like another dimension (create the location dim and link it to the measures in the database )

Thanks for your support.
Best Regards
Said

[Olivier Chapiteau (olivier-chapiteau)]

affected

[Philippe Boucher (boucherp)]

Created some releases and milestones for the data loader and assigned this bug to gho data loader release 1.0

[Jiri Dvorak (jiri-dvorak)]

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.

[Jiri Dvorak (jiri-dvorak)]

As this involves a potential scope change / new work, assigning to Philippe Boucher for decision.