Open ChristianZimpelmann opened 1 year ago
Let's see after #509 is implemented how many nested groupings are left (currently, tu always is a subset of hh, but not many things like that might be left).
Given that we don't want to implement #701 we can close this as well, right?
Probably yes. Is #445, which triggered this, still relevant? And when can we be sure that one group is a subset of another? Would we need a check?
Correct me if I'm wrong:
The following groups should not be subsets of each other:
sn
and hh
or fg
or bg
(taxes can be filed jointly even when getrennt lebend)ehe
and bg
or hh
or eg
(getrennt lebend)The following should always be subsets:
eg
is a subset of bg
bg
is always a subset of fg
fg
is always a subset of hh
We could make aggregations possible for the second list and rely on user-provided aggregations for the first list.
Cool, then let's keep this open for the moment. We will need to worry about how to ensure nesting then. Maybe we should restrict ourselves to sums, too.
Is your feature request related to a problem?
eink_st_tu
) on hh level (e.g.arbeitsl_geld_2_eink_m_hh
).eink_st_tu / anz_erwachsen_tu
) and aggregating this variable on hh level.Describe the solution you would like to see
eink_st_hh
based oneink_st_tu
def grouped_sum(column, group_id):
)def grouped_sum_from_grouped(column, group_id_input, group_id_output):
)Describe alternatives you've considered
Leave as is.