---
title: "Important: Remaining unordered queries now order by uid"
manual: "Academic Profiles"
version: "main"
source: "Changelog/3.0/Important-RemainingUnorderedQueriesOrderByUid.rst"
rendered: "2026-10-02T20:47:49+00:00"
---

# Important: Remaining unordered queries now order by uid {#important-remaining-unordered-queries-order-by-uid}

## Description {#description}

The sweep that ordered the unordered profile queries (see
[Important: Unordered profile queries now order by uid](Important-UnorderedQueriesOrderByUid.html#important-unordered-queries-order-by-uid)) missed five query paths, which
kept returning rows in whatever order the database yielded:

-   `ContractRepository::findAll()`, which builds every contract select
    item in the backend (TCA `itemsProcFunc` and FlexForm)
-   `ContractRepository::findByUids()` and
    `ContractRepository::findByUidsWithContext()`, the latter of which
    resolves the contracts of the "selected contracts" plugin
-   `ProfileRepository::findByUids()` and
    `ProfileRepository::findByUidsWithContext()`, the latter of which
    resolves the profiles of the "selected profiles" plugin
-   `ProfileRepository::findByFrontendUser()`, which resolves the profiles
    of a frontend user for the frontend editing of
    `academic_persons_edit`
-   `ProfileRepository::findByDemand()` with a non-empty demanded ordering
    — the list plugin's **Sort by** — which carried no tiebreaker, so
    profiles equal in it (two people sharing a last name) had no defined
    relative order

The first four now order by `uid` ascending; the demanded ordering keeps
winning and gets `uid` ascending appended as a tiebreaker.

Three further methods ordered by `sorting` alone:
`AddressRepository::findByContractIncludingHidden()`,
`EmailRepository::findByContractIncludingHidden()` and
`PhoneNumberRepository::findByContractIncludingHidden()`, which list the
contact records of a contract for the frontend editing. Records can share a
`sorting` value, and within it their relative order was whatever the
database yielded. All three now append `uid` ascending as the tiebreaker.

## Impact {#impact}

No visible change is expected on SQLite, MySQL and MariaDB: `uid` ascending
is the order they return in practice, and it is guaranteed now rather than
coincidental. PostgreSQL promises no order without one, so an installation on it
may see such a list change once.

For the two uid selection methods the order of the editor's selection is
deliberately **not** reproduced — `in()` does not preserve it, and it was
never delivered before. Honouring the selection order would be a behaviour
change beyond making the lists reproducible.

## Affected Installations {#affected-installations}

Every installation of this extension.