Skip to content

Update warning about split queries and ordering#5420

Open
ali-alo wants to merge 1 commit into
dotnet:mainfrom
ali-alo:patch-1
Open

Update warning about split queries and ordering#5420
ali-alo wants to merge 1 commit into
dotnet:mainfrom
ali-alo:patch-1

Conversation

@ali-alo

@ali-alo ali-alo commented Jul 9, 2026

Copy link
Copy Markdown

Removes a redundant use of "each" in the EF Core documentation.

Copilot AI review requested due to automatic review settings July 9, 2026 17:26

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Refines the EF Core documentation warning about split queries with Skip/Take by removing redundant wording to make the guidance clearer.

Changes:

  • Removed redundant “each” in the split-queries warning example text.
  • Kept the guidance about fully-unique ordering for split queries with pagination intact.


> [!WARNING]
> When using split queries with Skip/Take on EF versions prior to 10, pay special attention to making your query ordering fully unique; not doing so could cause incorrect data to be returned. For example, if results are ordered only by date, but there can be multiple results with the same date, then each one of the split queries could each get different results from the database. 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.
> When using split queries with Skip/Take on EF versions prior to 10, pay special attention to making your query ordering fully unique; not doing so could cause incorrect data to be returned. For example, if results are ordered only by date, but there can be multiple results with the same date, then each one of the split queries could get different results from the database. 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.
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.

2 participants