perf(datasource-toolkit): cache collection name & lookups in serialization

[matthv]

Context

Serializing a collection list re-resolves collections per record and per relation by walking the decorator stacks. Profiling a 100-row related list (.../relationships/transactions?page[size]=100) with stackprof showed ~54% of request wall-time in:

• ForestAdminDatasourceToolkit::Decorators::CollectionDecorator#name (46% self) — @child_collection.name re-chains the whole collection-decorator stack on every call (~89k calls over the burst);
• ForestAdminDatasourceToolkit::Decorators::DatasourceDecorator#get_collection — re-descends the datasource-decorator stack on every call and recomputes collection.name to key its cache.

The JSON:API serializer (ForestSerializer#id, #relationships, #attributes) calls these once per record, so the cost is O(records × relations × decorator-depth). SQL for the same request is ~1ms.

Change

Memoize results that are immutable after the datasource is built:

• CollectionDecorator#name caches into @memoized_name. (Not @name: the base Collection#initialize(datasource, name, …) sets @name, and CollectionDecorator#initialize(child_collection, datasource) calls super without parens, so @name already holds the datasource object — reusing it makes name return the datasource. A rubocop:disable Naming/MemoizedInstanceVariableName documents this.)
• DatasourceDecorator#get_collection caches the decorator by the requested name (@collections_by_name), keeping the existing @decorators-by-resolved-name behaviour so a collection reachable under multiple names still gets a single decorator instance.
• ForestSerializer#id caches primary keys per type (@@primary_keys) instead of resolving the collection and its keys for every record.

No behavioural change — names and primary keys are fixed after build; caches live on the persistent decorator/serializer objects and reset naturally on datasource reload.

Measured effect

Bench app (Postgres, 5000 transactions), median of 7, warm. Same JSON output:

endpoint	before	after
related list of 100	58 ms	9.6 ms
root list of 100	203 ms	27 ms
root list of 15	38 ms	10.5 ms
deep-relation list of 100	119 ms	16 ms
record show	11 ms	5.9 ms

The win applies to all list serialization, not just related lists (these lookups are on the render path of every collection).

Tests

Full package suites green: forest_admin_datasource_toolkit 463/0, forest_admin_agent 719/0, forest_admin_datasource_customizer 689/0. RuboCop clean.

🤖 Generated with Claude Code

Note

Cache collection name and primary-key lookups in datasource serialization

• Memoizes the collection name in CollectionDecorator using a dedicated @memoized_name variable to avoid clashing with the base class @name.
• Memoizes get_collection results by name in DatasourceDecorator via @collections_by_name, avoiding repeated child datasource lookups.
• Caches primary keys per collection type in ForestSerializer using a class-level @@primary_keys hash, with a new reset_cache! method to clear it.
• Calls ForestSerializer.reset_cache! during AgentFactory.reload! so stale primary-key data is cleared on agent reload.

^{Macroscope summarized ba5fa45.}

[forest-bot]

🎉 This PR is included in version 1.35.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀