|
| 1 | +# Transition Guide: Moving to the New Entity Links |
| 2 | + |
| 3 | +With the release of the **Generic Entity Links** API, OpenFisca-core gains the ability to map complex, graph-like relational structures natively. |
| 4 | + |
| 5 | +This guide explains the primary differences between the legacy `GroupEntity` + `Projectors` approach and the flexible, modern `Many2OneLink` and `One2ManyLink` models, and how you should think about migration. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## 1. Why Transition? The "Strict Hierarchy" Problem |
| 10 | + |
| 11 | +Historically, OpenFisca rigidly structured populations into two classes: `SingleEntity` (Persons) and `GroupEntity` (Households, Families, Tax Units). |
| 12 | + |
| 13 | +In this model, **every person must belong to exactly one entity of each group type.** |
| 14 | +This handles standard socio-tax models efficiently, but prohibits features like: |
| 15 | +- **Intra-entity (horizontal) relations**: Modeling a mother/child bond, marriages, or kinship networks. *Persons couldn't map to other Persons.* |
| 16 | +- **Unbounded inter-entity relations**: Employment networks where one `company` controls multiple `persons`, or geographical relations (people living in specific arbitrary administrative districts). |
| 17 | + |
| 18 | +**The Solution:** The new Entity Links system is purely arbitrary and structural. You can declare `Many2OneLink` (N source members to 1 target entity) or `One2ManyLink` (aggregating 1 target back to N source members) linking *any population type to any other population type.* |
| 19 | + |
| 20 | +--- |
| 21 | + |
| 22 | +## 2. You don’t *have* to migrate existing simple groups. |
| 23 | + |
| 24 | +**Backward Compatibility is 100% Guaranteed.** |
| 25 | + |
| 26 | +If you have a traditional `GroupEntity` defined for households, those work exactly as they always have. In fact, OpenFisca now silently powers them using the new Linking engine gracefully: |
| 27 | +- The legacy `person.household(...)` projector maps to a new automatically injected `ImplicitMany2OneLink`. |
| 28 | +- The legacy `household.sum(person_salaries)` maps logically to `household.persons.sum()`. |
| 29 | + |
| 30 | +No code change is required in any existing variable formulas! |
| 31 | + |
| 32 | +--- |
| 33 | + |
| 34 | +## 3. From Projectors to Links: The New Syntax |
| 35 | + |
| 36 | +If you previously dealt with `Projectors`, you may have found chaining difficult or buggy. The new system standardizes data lookup through `link.get()` and properties filtering. |
| 37 | + |
| 38 | +### Before: Projectors |
| 39 | +If you wanted the value of `rent` for the household of a person: |
| 40 | +```python |
| 41 | +# Projector syntax |
| 42 | +rents = person.household("rent", period) |
| 43 | +``` |
| 44 | + |
| 45 | +### After: Link Syntax |
| 46 | +The same syntax continues to work (it actually calls `.get()` internally now on the implicitly generated link!), but you can explicitly specify `.get()`: |
| 47 | +```python |
| 48 | +# New link syntax |
| 49 | +rents = person.household.get("rent", period) |
| 50 | +``` |
| 51 | + |
| 52 | +**Where the new syntax shines:** Deep chaining. |
| 53 | +You can now continuously resolve attributes down a deep relationship chain effortlessly: |
| 54 | +```python |
| 55 | +# Imagine a link: `person -> mother_person -> mother_household -> region` |
| 56 | +chain = person.mother.household.get("region", period) |
| 57 | +``` |
| 58 | + |
| 59 | +--- |
| 60 | + |
| 61 | +## 4. Transitioning Aggregations: `sum`, `count`, `min`, `max` |
| 62 | + |
| 63 | +Previously, aggregating members relied rigidly on passing entire pre-computed arrays to a heavy `GroupPopulation.sum()` handler. |
| 64 | + |
| 65 | +### Before: Legacy GroupPopulation |
| 66 | +```python |
| 67 | +# Fetch array of all persons in simulation |
| 68 | +salaries = persons("salary", period) |
| 69 | +# Pass to the group entity (e.g. household) to aggregate and collapse |
| 70 | +total_household_incomes = households.sum(salaries, role=Household.PARENT) |
| 71 | +``` |
| 72 | + |
| 73 | +### After: Declarative Links |
| 74 | +```python |
| 75 | +# The logic operates directly on the `One2ManyLink` bridging the two entities. |
| 76 | +total_household_incomes = households.persons.sum("salary", period, role=Household.PARENT) |
| 77 | +``` |
| 78 | +Notice how declarative and explicit this is. `persons` is the plural of `person`, which the new system automatically exposed as a `One2ManyLink` on your household. |
| 79 | + |
| 80 | +### Conditional Aggregations |
| 81 | +A newly-available feature explicitly unlocked by the Link system is masking by arbitrary properties! You are no longer restricted strictly to OpenFisca Roles: |
| 82 | +```python |
| 83 | +is_female = persons("is_female", period) |
| 84 | +# Sum salaries, but only for members who are `is_female` |
| 85 | +female_incomes = households.persons.sum("salary", period, condition=is_female) |
| 86 | +``` |
| 87 | + |
| 88 | +--- |
| 89 | + |
| 90 | +## 5. Summary Checklist for Country Packages |
| 91 | +- [ ] You **do not** need to rewrite `GroupEntity` logic for entities whose only purpose is traditional demographic grouping (like core households). |
| 92 | +- [ ] You **can** start using `households.persons.sum()`, `households.persons.any()`, `households.persons.avg()` for highly readable aggregations in new variables. |
| 93 | +- [ ] You **should** use `Many2OneLink` immediately if your simulation model attempts to relate `persons` to specific entities beyond openfisca-standard hierarchical groups (like a `mother_id` linking to another row in the `persons` dataframe). |
| 94 | + |
| 95 | +Please see the full `links-api.md` file in this directory to see exactly how to declare explicit `Many2OneLink` models inside your `TaxBenefitSystem`. |
0 commit comments