---
title: "Important: Partner queries are ordered deterministically"
manual: "Academic Partners"
version: "3.0"
permalink: "https://docs.typo3.org/permalink/fgtclb/academic-partners:important-partner-queries-are-ordered-deterministically@3.0"
source: "Changelog/2.4/Important-PartnerQueriesAreOrderedDeterministically.rst"
rendered: "2026-10-26T17:55:16+00:00"
---

# Important: Partner queries are ordered deterministically {#important-partner-queries-are-ordered-deterministically}

## Description {#description}

Most queries of this extension executed without an ordering, so the order of
their result was whatever the database happened to yield. On PostgreSQL that is
not reliably the same list twice, so a partnership teaser could render a
different partner on two renders of the same data. The queries now order
explicitly:

-   `PartnershipRepository::findByPid()`, the source of every partnership
    list and teaser, orders by the manual backend `sorting` (TCA ctrl
    `sortby`), with `uid` settling ties.
-   `PartnerRepository::findByDemand()`, the source of the partner list
    and the partner map, appends `uid` as a tiebreaker to the ordering the
    plugin demands. Records equal in that ordering, two partners with the same
    title for example, keep a stable relative order.
-   `PartnerRepository::findNextForGeolocation()` processes the geocoding
    queue oldest record first (`uid` ascending) instead of letting the
    database pick.
-   `PartnerRepository::findAll()` and `findGeoLocated()` order by
    the backend `sorting` of the page records, with `uid` settling
    ties. Partner records are pages, so among siblings this is the order the
    editor arranged in the page tree.

## Impact {#impact}

Partnership lists and teasers now render in the order of the partnerships'
`sorting`. Partnerships are inline records of their partner page: a new
one is added at the bottom, and saving the page numbers them in the order of
its form, so a list maintained on the partner page keeps its oldest-first
order unless an editor rearranged it. They are inline records of their role as
well, and that relation wrote the same `sorting` column until the role
gained a sort column of its own, see
[Important: A partner role sorts its partnerships on its own](https://docs.typo3.org/permalink/fgtclb/academic-partners:important-partner-role-sorts-its-partnerships@3.0).

The partner list and the partner map keep the ordering configured in the
plugin. Only partners that are equal in it are ordered by `uid` now.

The geocoding queue and the tiebreakers use `uid` ascending, the order
SQLite, MySQL and MariaDB return in practice. On PostgreSQL the previous order
was not reliable to begin with.

Nothing the extension renders reads `findAll()` or `findGeoLocated()`
in an order that shows: the partner select of a partnership record sorts its
entries by label, see [Important: The partner select is sorted by label](https://docs.typo3.org/permalink/fgtclb/academic-partners:important-ace-669-academic-partners@3.0). Code of a
project that calls them gets the page tree order. The backend typically places
a page created below a parent page above the existing ones, so partner pages
nobody rearranged come out newest first, where the database returned them
oldest first.

## Affected Installations {#affected-installations}

Every installation of this extension. Nothing has to be done on update.