Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Doctrine ORM/ODM resource metadata collection factory runs outside the metadata cache since 4.2.16 (priority -50 vs `.cached` at -10)

Đang mở
  • Có gì không ổn?
#8,769 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Pixelshaped đang làm issue này rồi.

Từ ngày 27/10/2026.

  • #8770 của @Pixelshaped — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
68/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php, symfony
Lĩnh vực
backend, performance

Hướng nghiên cứu

Read the Doctrine ORM and ODM service definitions in src/Symfony/Bundle/Resources/config/doctrine_orm.php and src/Symfony/Bundle/Resources/config/doctrine_mongodb_odm.php, then compare their decoration priorities with the cached factory in metadata/metadata.php. Reproduce with a Symfony app using Doctrine and profile a request that serializes an item with many related resources. Done when both factories run behind the cache and the issue’s repeated calls are avoided without changing the response.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

API Platform version(s) affected: 4.2.16 and later, including 5.0.x (measured on 5.0.2) and main

Description

Since #7739 (merged 2026-02-13 as 6f85f2aa3157, first released in v4.2.16), the Doctrine resource metadata collection factories are decorated at priority -50 instead of 40:

  • api_platform.doctrine.orm.metadata.resource.metadata_collection_factory in src/Symfony/Bundle/Resources/config/doctrine_orm.php
  • api_platform.doctrine.odm.metadata.resource.metadata_collection_factory in src/Symfony/Bundle/Resources/config/doctrine_mongodb_odm.php

api_platform.metadata.resource.metadata_collection_factory.cached (CachedResourceMetadataCollectionFactory) is at -10 in metadata/resource.php and has been the lowest-priority (outermost) decorator since 2.7. With -50, the Doctrine factory now wraps the cache instead of sitting behind it, so DoctrineOrmResourceCollectionMetadataFactory::create() is no longer cached and re-runs on every create() call, including one ManagerRegistry::getManagerForClass() call per resource it processes.

Moving from 40 to -50 only jumps over the cache decorator (-10) and Elasticsearch (also 40, so a tie). The discussion in #7739 never mentions the cache, so the bypass looks unintended. For comparison, the Laravel wiring (src/Laravel/ApiPlatformDeferredProvider.php) builds new CacheResourceCollectionMetadataFactory(new EloquentResourceCollectionMetadataFactory(...)), i.e. its equivalent stays inside the cache.

Measured in a Symfony app on 5.0.2, serializing one item that references ~1,000 related resources (JSON-LD):

  • 3,407 uncached DoctrineOrmResourceCollectionMetadataFactory::create() calls and 27,270 ManagerRegistry::getManagerForClass() calls for that single request, coming from AbstractItemNormalizer::normalizeCollectionOfRelations and the JSON-LD ItemNormalizer::resolveType.
  • About 24% of the profiled request (Xdebug profile: 13,206 → 9,340 ms with the factory back inside the cache).
  • Without the profiler (Xdebug off, median of 5 runs): ~905 ms → ~685 ms. SQL queries and response size are unchanged and the JSON output is byte-identical.

How to reproduce

  1. Symfony app with API Platform ≥ 4.2.16 and Doctrine ORM.
  2. A resource with a to-many relation and one item with a few hundred related items.
  3. GET that item (application/ld+json) while profiling (Blackfire / Xdebug / SPX).
  4. DoctrineOrmResourceCollectionMetadataFactory::create() and ManagerRegistry::getManagerForClass() show up thousands of times for the one request, although the metadata below the Doctrine factory is cached.

The wiring is visible directly in the config: priority -50 for the Doctrine factory vs -10 for .cached (lower priority = outermost).

Possible Solution

Use a priority between the cache (-10) and the other regular factories, for both ORM and ODM. The smallest change is -5; going back to 40 should work too, unless something from #7739 needs to run after a lower-priority factory (I couldn't find a reason in the PR).

->decorate('api_platform.metadata.resource.metadata_collection_factory', null, -5)

Workaround for applications: redeclare the Doctrine factory service in config/services.yaml with decoration_priority: -5 (repeating its constructor arguments from the bundle definition). That restores the cached behaviour here.

Additional Context

DoctrineOrmResourceCollectionMetadataFactory::create() mutates the Operations object it receives from the decorated factory. Once its input comes from the cache's local in-memory store, that object is shared across calls. It is idempotent today (the same values are written each time), so it should be fine, but it's worth keeping in mind (or cloning) if the factory ever becomes dependent on anything other than the resource class.

Ngôn ngữ chính
PHP
Star
2.6k
Fork
987
Merge trung bình
1 ngày 22 giờ
Pull request đã merge (30 ngày)
87

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của api-platform/core

Tất cả issue của api-platform/core

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.