PersistentCollection::matching() does not respect the collections native sorting #6266

New Issue

admin · 2026-01-22T15:29:52+01:00

admin commented

2026-01-22 15:29:52 +01:00

Originally created by @stephanschuler on GitHub (Jul 1, 2019).

Originally assigned to: @lcobucci on GitHub.

Bug Report

When PersistentCollection::matching() is called, the result in terms of sorting depends on the collection being initialized or uninitialized.

Q	A
BC Break	no
Version	2.5

Summary

On an initialized collection, the "matching" is applied to the array content, which means sorting is basically untouched if the criteria does not provide additional sorting.

On an unitialized collection, the "matching" is queried through the database. Here the sorting of the collection isn't considered, only the sorting of the criteria is. More often than not, no predictable sorting is used here -- whenever the criteria comes without custom sorting.

Current behavior

PersistentCollection->matching(Criteria::create()) without sorting doesn't use the collections sorting either.

How to reproduce

Used the Ecommerce category as a test case.
Make Category::$children @ORM/OrderBy({"name" = "ASC"})
Fill unordered data
As for $category->getChildren()->matching(Criteria::create()).

The result is not ordered according to the annotation.

Expected behavior

The result should be ordered according to the annotation.

Originally created by @stephanschuler on GitHub (Jul 1, 2019). Originally assigned to: @lcobucci on GitHub. ### Bug Report When PersistentCollection::matching() is called, the result in terms of sorting depends on the collection being initialized or uninitialized. | Q | A |------------ | ------ | BC Break | no | Version | 2.5 #### Summary On an initialized collection, the "matching" is applied to the array content, which means sorting is basically untouched if the criteria does not provide additional sorting. On an unitialized collection, the "matching" is queried through the database. Here the sorting of the collection isn't considered, only the sorting of the criteria is. More often than not, no predictable sorting is used here -- whenever the criteria comes without custom sorting. #### Current behavior `PersistentCollection->matching(Criteria::create())` without sorting doesn't use the collections sorting either. #### How to reproduce - Used the Ecommerce category as a test case. - Make Category::$children `@ORM/OrderBy({"name" = "ASC"})` - Fill unordered data - As for `$category->getChildren()->matching(Criteria::create())`. The result is not ordered according to the annotation. #### Expected behavior The result should be ordered according to the annotation.

admin added the Bug label 2026-01-22 15:29:52 +01:00

admin closed this issue

2026-01-22 15:29:52 +01:00

admin commented

2026-01-22 15:29:52 +01:00

@stephanschuler commented on GitHub (Jul 1, 2019):

First I was under the impression it's issue #6516. But that's not the case: There it's about matching not using the order of the criteria. Which is the exact opposite of what I'm experiencing.

I provided a PR with a test case.

See:
https://github.com/doctrine/orm/pull/7766

Tests 1 and 3 (testMatchingWithNoOrderingUsesDatabaseDefault and testMatchingOverrulesCollectionOrdering) are fine even without my patch.
Test 2 (testMatchingRespectsCollectionOrdering) is the thing failing without my patch.

I added all of those to make sure my patch wouldn't break existing behavior.

@stephanschuler commented on GitHub (Jul 1, 2019): First I was under the impression it's issue #6516. But that's not the case: There it's about matching not using the order of the criteria. Which is the exact opposite of what I'm experiencing. I provided a PR with a test case. See: https://github.com/doctrine/orm/pull/7766 - Tests 1 and 3 (testMatchingWithNoOrderingUsesDatabaseDefault and testMatchingOverrulesCollectionOrdering) are fine even without my patch. - Test 2 (testMatchingRespectsCollectionOrdering) is the thing failing without my patch. I added all of those to make sure my patch wouldn't break existing behavior.

admin commented

2026-01-22 15:29:53 +01:00

@lcobucci commented on GitHub (Aug 13, 2019):

Handled by #7766

@lcobucci commented on GitHub (Aug 13, 2019): Handled by #7766

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6266