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

# Important: Unordered profile queries now order by uid {#important-unordered-queries-order-by-uid}

## Description {#description}

Five query paths of this extension executed without any ordering, so the order
of their result was whatever the database happened to yield:

-   `ProfileRepository::findAll()`
-   `ProfileRepository::findByDemand()` whenever the demand yields no
    ordering — which is what the list plugin's **Sort by** option
    **none** means
-   `LocationRepository::findAll()`,
    `FunctionTypeRepository::findAll()` and
    `OrganisationalUnitRepository::findAll()`, which fill the location,
    function type and organisational unit selects of the contract form in
    `academic_persons_edit`

All five now order by `uid` ascending when nothing else asks for an
order.

## Impact {#impact}

No visible change is expected on SQLite, MySQL and MariaDB. They returned
insertion order for these queries in practice, and `uid` ascending is that
same order — the assertions of the affected functional tests are unchanged,
they are simply guaranteed now rather than coincidental. PostgreSQL promised no
order, as the next paragraph shows.

What changes is that the order is reproducible. It previously depended on the
database, its version and which indexes existed, and could therefore change
under an installation without any content change. That is not hypothetical:
making the person tables workspace aware in the same release added an index
over `t3ver_oid`, which gave the PostgreSQL planner a way to satisfy the
`t3ver_oid = 0` constraint Extbase adds for a workspace aware table, and
reversed the result of exactly these queries.

The TCA `default_sortby` of the location, function type and organisational
unit tables still does **not** apply to their `findAll()`. That was never
the case and is not changed here — it orders the record lists of the backend,
not the selects of the frontend edit form.

## Affected Installations {#affected-installations}

Every installation of this extension. An installation that already sets a
sorting on the list plugin is unaffected either way, because an explicit
ordering always won.