Document behavior of AsSplitQuery() when subquery has unstable ordering

[angelaki]

I'm sorry I cannot fully reproduce this error yet, but as I already described in a just created stackoverflow (https://stackoverflow.com/questions/67169707/azure-sql-queries-with-same-order-returning-different-resultsets) Azure SQL somehow seams to have problem keeping the order for some queries. This sure breaks the logic of your "AsSplitQuery()" so that I needed to remove it completely and live with the performance decrease.

Is this maybe an already known misbehavior? Is there something I can do to make it work? Anyways, I thought you should know this.

Edit: I now know that SQL Server is not guaranteed to keep the order between queries for not unique columns! The order is determined based on indexes, columns etc.. But what to do in these cases? Guess I'm not the last one to fall in this pit. I now append a .ThenBy(e => e.UniqueIdentifier) everytime a order is attached. But it's a pretty technical reason causing this issue and will sure confuse several persons out there!

I don't know how complex this could be under the hood, but would it be possible to always order by entities PK last if any / no orders are used? Guess it's getting pretty tricky right now but it is a terrible pitfall right now!

[ajcvickers]

@angelaki EF Core should be ensuring a unique ordering when generating SQL for a split query, so it sounds like this is a bug. Please attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate.

[angelaki]

What should have been the expected behavior? Should it get ordered by Id last by default? I'll try my very best, but isolating this issue seams pretty tricky.

[smitpatel]

EF Core split query will add ordering by PK automatically. It is appended after the ordering specified by the user so that user gets results in the order they asked. So Split queries always have a stable and unique-ly identifying ordering. So the issue you are describing doesn't really occur for split query in theory. So you will need to provide a full repro which shows that split query is not working correctly due to aforementioned reason. It is likely that you are running into a different issue.

[angelaki]

Sorry, I'm pretty busy these days, but I'll try to isolate the issue next weekend. It's a querable pushed through multiple services, getting dynamicly ordered by expressions etc..

[ajcvickers]

EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.

BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.

[angelaki]

Sorry it took me a while to isolate the issue - it actually was pretty easy. Here you go:

public class Appointment
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public DateTime? Start { get; set; }
    public ICollection<AppointmentParticipant> Participants { get; set; }
}

public class AppointmentParticipant
{
    public Guid UserId { get; set; }
    public Guid AppointmentId { get; set; }
    public Appointment Appointment { get; set; }
}

_dbContext.Appointments.Include(p => p.Participants).AsSplitQuery().OrderBy(a => a.Start).Skip(10).Take(10).ToArrayAsync();

generates the following SQL:

SELECT [t].[Id], [t].[Name], [t].[Start]
FROM (
    SELECT [a].[Id], [a].[Name], [a].[Start]
    FROM [Appointment] AS [a]
    ORDER BY [a].[Start]
    OFFSET @__p_0 ROWS FETCH NEXT @__p_0 ROWS ONLY
) AS [t]
ORDER BY [t].[Start], [t].[Id]

As you can see the INNER SQL is sorted wrong! Furthermore I noticed:

• .Take(X).Skip(X) (reverse Order) generates wrong SQLs
• Order after .Take(X).Skip(X) generates wrong SQLs

But that's ok for me. Intended behavior?

[roji]

@angelaki what exactly is wrong with the inner SQL? It seems to sort by Start as you've requested in the LINQ query, no?

.Take(X).Skip(X) (reverse Order) generates wrong SQLs

Take/Skip does not do reverse ordering - try using these operators in LINQ to Objects (without EF Core) to see the expected behavior. If you think the EF-generated SQL is wrong with regards to that, please open an issue with the exact SQL you're seeing and why it doesn't seem right.

Order after .Take(X).Skip(X) generates wrong SQLs

Here too, I'm guessing your expectations may not be accurate. Take/Skip without a preceding OrderBy are problematic, since in SQL table/subquery rows have no determinate order; so what actual rows get selected is completely non-deterministic. Once again, if you suspect a real issue, please open a separate issue with a full LINQ query and the generated SQL.

[angelaki]

Thank you for the explanation about these two behaviors! 👍

Back to my initial issue:

As you can see the outer SQL is ordered by Start and Id to ensure the data is always returned in the same order. Id gets added by some EFCore magic I guess - I never actually sorted by it. Since the Inner Query gets only ordered by Start (what is not unique) its order is not deterministic (at least not enough, since it changes depending on selected fields [SQL Server optimization etc.]).

Now that I use .AsSplitQuery() the second query will try to get all the participants the first query returned. It will use the same subquery, bit since no columns are actually selected this time the order changes and the SplitQuery return the participants from different appointments!

It sure still works if I manually order by Start and Id, but as @ajcvickers and @smitpatel mentioned this should work "out of the box"

[roji]

Reopening to let @smitpatel take a look.

[smitpatel]

The SQL generated by EF Core is accurate. We generate OrderBy-Apply Skip/Take and then add ordering we require so result set is pre-defined.

Now the ordering being non-unique is not entirely issue as long as Skip/Take are not crossing duplicate column set. e.g. If you are sorting by City and values are New York, New York, Seattle, Seattle and you do Skip(0).Take(3) then which row with city value Seattle will be picked is non-deterministic. If you do Take(2) then subquery may not have exact ordering but it will select same rows and then outer query will order them uniquely.

If your main result set is non-deterministic because of the combination of OrderBy/Skip/Take specified then you will get whatever results server gets. Neither EF Core can predict that it will be problematic (since it is data dependent), nor EF Core can do anything fix is because it may change expected results and add additional (at times significant) perf.

[angelaki]

Yes, I totally agree with you. But in my case AsSingleQuery still works while AsSplitQuery is broken since the reload (appointment participants) targets different rows!

[smitpatel]

When the issue happens only when you run query multiple times then it would only happens when using AsSplitQuery. Again, EF Core cannot do anything here.

[angelaki]

No, AsSplitQuery runs two queries! But the 2nd one does not contain the records of the first one! Just like the outer query gets the primary key as order criteria attached, the inner one needs it, too.

Do you need more code to reproduce it? I just skipped pasting the second query getting executed by one EFCore action.