For example, if results are ordered only by date, but there can be multiple results with the same date, then results could be skipped when paginating as they're ordered differently across two paginating queries. Ordering by both date and ID (or any other unique property or combination of properties) makes the ordering fully unique and avoids this problem. Note that relational databases do not apply any ordering by default, even on the primary key.
Expected queries to allways contain orderBy PK, with priority to the specified $orderBy (if any), so if one passes:
/resource?$orderby=type desc
the expected query should be
SELECT *
FROM "TEntitiy" AS "c"
ORDER BY "c"."Type" DESC, "c"."Id" DESC
Actual behavior
When one doesn't pass any $orderBy, the expression is added with default OrderBy PK (not sure if this is by EF itself or by the library), but when one passes /resource?$orderby=type desc there is no additional orderBy by another unique column.
SELECT *
FROM "TEntitiy" AS "c"
ORDER BY "c"."Type" DESC
Version: 5.0.2
Expected behavior
Queries should contain fully unique OrderBy clause EF Core Pagination.
For example, if results are ordered only by date, but there can be multiple results with the same date, then results could be skipped when paginating as they're ordered differently across two paginating queries. Ordering by both date and ID (or any other unique property or combination of properties) makes the ordering fully unique and avoids this problem. Note that relational databases do not apply any ordering by default, even on the primary key.
Expected queries to allways contain orderBy PK, with priority to the specified $orderBy (if any), so if one passes:
/resource?$orderby=type desc
the expected query should be
Actual behavior
When one doesn't pass any
$orderBy
, the expression is added with default OrderBy PK (not sure if this is by EF itself or by the library), but when one passes/resource?$orderby=type desc
there is no additional orderBy by another unique column.