Skip to content

Make EnsureStableSortOrderBy respect the ordering direction for added fields#1560

Open
jbaehr wants to merge 1 commit intoOData:mainfrom
jbaehr:propagate-direction-for-stable-ordering
Open

Make EnsureStableSortOrderBy respect the ordering direction for added fields#1560
jbaehr wants to merge 1 commit intoOData:mainfrom
jbaehr:propagate-direction-for-stable-ordering

Conversation

@jbaehr
Copy link

@jbaehr jbaehr commented Feb 20, 2026

Previously, the fields added to the $orderby clause to enable stable ordering were always in ascending order -- no matter what the original sorting order was. This has led to two undesired side effects:

  • As a user, I expect my results to be returned in reverse order if I switch from asc to desc. Yet the order of items sharing the same value for my original sorting criterion were not reversed.
  • As a developer, I expect the same indices to be used (just traversed in reverse order) if the sorting order from the user query is reversed. Yet the generated query is not simply reversed, preventing the same composite indices to be used. E.g. for MongoDB this currently requires an additional index.

This commit addresses both issues by propagating the sorting order of the last user-provided ordering criterion to all additional criteria required to stabilize the ordering. So when the original query was "$orderby=Foo" I got (and still get) an ordering of "Foo asc, Id asc". Reversing this to "$orderby=Foo desc" I previously got "Foo desc, Id asc" and now get "Foo desc, Id desc". This means an index on {Foo:1, Id:1} can be used for both queries while previously an additional index on {Foo:-1, Id:1} was required (example for MongoDB).
And for the user a result of "(A,1);(A,2); ... (Z,55);(Z,66)" reversed is now "(Z,66);(Z55); ... (A,2);(A,1)" as intuitively expected. Previously it was "(Z55);(Z,66); ... (A,1);(A,2)".

Previously, the fields added to the $orderby clause to enable stable
ordering were always in ascending order -- no matter what the original
sorting order was. This has led to two undesired side effects:
- As a user, I expect my results to be returned in reverse order if I
  switch from asc to desc. Yet the order of items sharing the same value
  for my original sorting criterion were not reversed.
- As a developer, I expect the same indices to be used (just traversed
  in reverse order) of the sorting order from the user query is reversed.
  Yet the generated query is not simply reversed, preventing the same
  composite indices to be used. E.g. for MongoDB this currently requires
  an additional index.

This commit addresses both issues by propagating the sorting order of
the last user-provided ordering criterion to all additional criteria
required to stabilize the ordering. So when the original query was
"$orderby=Foo" I got (and still get) an ordering of "Foo asc, Id asc".
Reversing this to "$orderby=Foo desc" I got "Foo desc, Id asc" and now
get "Foo desc, Id desc". This means an index on {Foo:1, Id:1} can be used
for both queries while previously an additional index on {Foo:-1, Id:1}
was required (example for MongoDB).
And for the user a result of "(A,1);(A,2); ... (Z,55);(Z,66)" reversed
is now "(Z,66);(Z55); ... (A,2);(A,1)" instead of the previous
"(Z55);(Z,66); ... (A,1);(A,2)"
@jbaehr
Copy link
Author

jbaehr commented Feb 20, 2026

@microsoft-github-policy-service agree company="Rohde & Schwarz GmbH & Co. KG"

@jbaehr
Copy link
Author

jbaehr commented Mar 2, 2026

@xuzhg @gathogojr should I create a dedicated issue for the misbehavior fixed here or is the PR enough?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant