Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include possibility for meta-calls in API #779

Open
hmgaudecker opened this issue Jul 8, 2024 · 0 comments
Open

Include possibility for meta-calls in API #779

hmgaudecker opened this issue Jul 8, 2024 · 0 comments
Labels
api-redesign Anything related to the redesign of the top-level API. enhancement New feature or request

Comments

@hmgaudecker
Copy link
Collaborator

hmgaudecker commented Jul 8, 2024

This has come up during the discussions on #778 and related.

The graph relies on a 1:1 mapping of function arguments and data. But we need a (n unknown) number candidate contents of bg_id and wthh_id in order to determine the correct setting in households where we have more than one fg and/or more than one bg.

#778 solves this via a complex workaround, which involves manually using fg_id as a candidate bg_id. It only works for a small number of candidates and which requires fg_id == hh_id.

Instead, we should provide for an option to

  1. Call a part of the DAG / another function which returns all possible candidate bg_id-wthh_id constellations, which pass some "absolute" checks (e.g., we won't need to worry about households failing the wealth checks).
  2. Create a sub-DAG, which will output the required targets (here, probably something like whether a particular candidate allocation of bg_ids and wthh_ids is valid in the first place along with eligibility for and payments from arbeitsl_geld_2, kinderzuschl, wohngeld).
  3. Make checks like vorrang or günstiger based on the results from 2.

This will be complex, also for users. We may want to provide a shortcut that allows for the same setup as we used to have: bg_id == fg_id == wthh_id == hh_id, then the checks are trivial.

@hmgaudecker hmgaudecker added enhancement New feature or request api-redesign Anything related to the redesign of the top-level API. labels Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-redesign Anything related to the redesign of the top-level API. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant