[santichausis]

Problem

PokemonEvolutionSerializer.get_condition_expression and get_allowed_natures run one query per PokemonEvolution row. Milcery → Alcremie has 63 evolution rows, each with a condition_expression, so /evolution-chain/452/ takes 65 queries (63 of them to pokemon_v2_evolutionvariable).

Fix

Both tables are tiny (4 evolution variables, 25 natures). Each is loaded and serialized once, lazily, through a cached_property on the serializer instance, and each row picks its entries in Python, keeping the previous ordering. Variables are kept as (symbol, data) pairs rather than a dict, since symbol isn't unique across version groups. ListSerializer reuses a single child instance for every row, so this is one query per list of evolution details instead of one per row, and no state is shared across requests.

Verification

• Built the DB from the CSVs and serialized all 540 evolution chains before/after: byte-identical JSON for every chain, chain 452 drops from 65 to 3 queries (and its serialization from ~52 ms to ~32 ms locally, by not re-running the summary serializers per row), and no chain needs more. OpenAPI schema unchanged.
• Added a test that builds chains with 1 and 5 evolution rows (each with a condition_expression and nature_bitmask), asserts the query count is the same, and checks the resolved variables and natures. This is the first API test coverage for these two fields. It uses cachalot_disabled(), because inside the test transaction cachalot serves identical repeated queries from memory, which hides per-row queries. On master this test fails with 13 vs 5 queries.
• manage.py test pokemon_v2 (64 tests), ruff, and ty (no new diagnostics) pass.
• In production cachalot/Redis caches these queries, so the gain is mainly for cold-cache requests and fewer cache round-trips.
• Touches the same file as Fix N+1 query in evolution chain serializer #1688; whichever lands second will need a trivial rebase.

[FallenDeity]

lgtm :) thanks, just remove the comments on top of the properties

    # a list of pairs rather than a dict, since symbols aren't unique across version groups

its evident in the code

[Naramsim]

Removed the comment and merged, thanks! Let's see if this speeds up the cicd

[pokeapi-machine-user]

A PokeAPI/api-data refresh has started. In ~45 minutes the staging branch of PokeAPI/api-data will be pushed with the new generated data.

The staging branch will be deployed in our staging environment and the entire API will be ready to review.

A Pull Request (master<-staging) will be also created at PokeAPI/api-data and assigned to the PokeAPI Core team to be reviewed. If approved and merged new data will soon be available worldwide at pokeapi.co.