When fetching a number of entities via the REST API, entities which were matched by the search result, but which are also loaded indirectly through an association will be removed from the main result list.
For example:
When querying some products via /api/v1/product, Product A and Product B are part of the result set.
Product B is also fetched through the Product A -> Visibilities -> SalesChannel -> ProductVisibilities -> Product B chain of associations.
Actual Result: Product B will not appear as part of the top-level result set data because it's already present in included.
Expected Result: Product B will appear in data (as well as in included).
Note that the example might seem contrived due to the loaded association depth required to trigger the issue, but this is the simplest example we could find which uses Shopware's own entities. In one of our ERP use cases, the problem already occurs when loading two levels of associations.
This PR adds a unit test to assert that entities, that are fetched as a top-level result as well as associations, are still present in the top-level result of an api search request.
3. Describe each step to reproduce the issue or behaviour.
Run the test. The test will fail because one of the entities is missing from the top level result because it was only added as an association.
If you remove the associations from the request, both products are part of the top level result again.
4. Please link to the relevant issues (if any).
5. Checklist
[ ] I have written tests and verified that they fail without my change
[ ] I have squashed any insignificant commits
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[ ] I have read the contribution requirements and fulfil them.
1. Why is this change necessary?
When fetching a number of entities via the REST API, entities which were matched by the search result, but which are also loaded indirectly through an association will be removed from the main result list.
For example:
/api/v1/product
, Product A and Product B are part of the result set.Product A
->Visibilities
->SalesChannel
->ProductVisibilities
->Product B
chain of associations.Actual Result: Product B will not appear as part of the top-level result set
data
because it's already present inincluded
.Expected Result: Product B will appear in
data
(as well as inincluded
).Note that the example might seem contrived due to the loaded association depth required to trigger the issue, but this is the simplest example we could find which uses Shopware's own entities. In one of our ERP use cases, the problem already occurs when loading two levels of associations.
The reason can be found in the
JsonApiEncodingResult
. When the result entities are parsed, their associations are added as part of theincluded
array of the result: https://github.com/shopware/platform/blob/34780a0796d3ed887240d7cad86aa4b4424a819e/src/Core/Framework/Api/Serializer/JsonApiEncodingResult.php#L70-L81 When aProduct
entity references anotherProduct
through associations, the latter is added inincluded
and it's identifier is marked as "contained" in the result. When the latterProduct
is later parsed as part of the top level result, it is instead skipped, because it is already contained in the result (inincluded
): https://github.com/shopware/platform/blob/34780a0796d3ed887240d7cad86aa4b4424a819e/src/Core/Framework/Api/Serializer/JsonApiEncodingResult.php#L83-L882. What does this change do, exactly?
This PR adds a unit test to assert that entities, that are fetched as a top-level result as well as associations, are still present in the top-level result of an api search request.
3. Describe each step to reproduce the issue or behaviour.
Run the test. The test will fail because one of the entities is missing from the top level result because it was only added as an association. If you remove the associations from the request, both products are part of the top level result again.
4. Please link to the relevant issues (if any).
5. Checklist