While I guess that the renderers know how to handle such single-row resulting datasets, it comes as a surprise at first. For example when defining a cross tab data set with 3 rows, one would expect to fetch 3 rows as a result and not just one.
Do you recall what was the rationale behind this design?
@mksd good question and no I don’t recall. I do remember this being intentional, but I’m not sure if it was for a a particularly good reason. I think it is likely that it was simply a reflection / continuation of the various Cohort indicator DSDs that were also created around the same time - their purpose was to enable defining the primary queries and their disaggregations and then being able to efficiently retrieve those of interest. And we didn’t have a particularly good model for identifying a particular row in a data set, whereas we did have a paradigm for getting data for a particular column. Happy to discuss revisiting this.
I haven’t looked into it yet but I’m already wondering if you would know from the top of your head whether this would cause issues with the default renderers? Such as tabular data coming out as one row when it shouldn’t… etc?
@mksd, if you look at renderDefaultReport.jsp, you’ll see that there is some (hacky) code in there that aims to format MapDataSets as key/value pairs, unless they are generated by CohortCrossTabDataSetDefinitions, in which case they are rendered as a 2D table.