[snyaggarwal]

Refs OpenConceptLab/ocl_online#456

Problem

Concept lists with includeMappings=true serialized each concept's mappings separately, so lookups ran once per concept (~250 ms/row on CIEL).

Change

• ConceptAbstractSerializer.preload_page fetches all direct mappings for the page in one query (honouring mapTypes, targetRepoUrls, retired) and runs the OpenConceptLab/ocl_online#454 | Load list-row lookups once per page for concepts and mappings #936 load_list_fields once for them.
• SourceChildPageSerializer calls preload_page when the child serializer defines it.
• Collection views and includeInverseMappings keep the existing per-concept path.

Measured (local DB with full CIEL, 100 rows, includeMappings=true, cache cleared)

• Detail: 1,610 queries / 2,252 ms -> 125 queries / 645 ms
• mappingBrief=true: 2,226 ms -> 298 ms (query counter read 0, timing only)
• Response identical to the old one except the order of mappings within a concept, which was unspecified before and is now by id.

Not done

• Production timing of a 100-row CIEL page and the saved-page comparison (AC 2, 3 and 4).
• concept.get_latest_version() still runs once per concept.

Tests

New test_list_serializer_loads_page_mappings_once compares page output with row-by-row output and bounds query growth.

🤖 Generated with Claude Code

[snyaggarwal]

No blocking findings.

Verified the batched mapping lookup against the existing version-aware direct-mapping behavior, including map type, target repository, and retired filters. Collection and inverse-mapping paths remain unchanged.

Local verification:

• ConceptSerializersTest: 22 tests passed
• Pylint completed successfully (one non-blocking existing-style too-many-locals diagnostic)
• Snyk passed; GitHub Pylint check was still pending at review time.

Submitted as a comment because GitHub does not permit authors to approve their own pull requests.

[snyaggarwal]

Second-pass review: endpoint matrix

I traced the change through the broader concept-list surfaces:

• Source HEAD lists: batching is active.
• Source-version lists: batching is active and retains the existing version-aware mapping lookup.
• Concept version-history lists: batching is active.
• Global /concepts/: batching is active; matching on both mapping parent and concept/version IDs prevents cross-source association.
• Collection concept lists: batching is intentionally bypassed, preserving collection/expansion-aware mapping resolution.
• Explicit expansion concept lists: also bypassed because the view context contains collection, preserving existing behavior.
• Inverse mappings: bypassed everywhere, preserving the existing path.

Additional source/version/collection/global and mapping-access tests passed (8 tests). I found no concrete defect, so the clean verdict stands.

Remaining non-blocking coverage gap: the new PR test exercises a raw serializer page from one source. An API-level parameterized regression test covering includeMappings=true for source versions, collections, explicit expansions, and a multi-source global list would make this matrix explicit and guard the intentional bypasses.