Maurycy Markowski

this is a limitation of our navigation expansion logic. When processing SelectMany collection selector, we can only handle cases where the selecor itself is a NavigationExpansionExpression (e.g. c.Addresses or c.Associate.Addresses)

related: https://github.com/dotnet/efcore/issues/32957

April 12 is the liftable constant, May 29 I will have to check one by one because nothing immediately jumps out when I look at the prs

it still repros on current main, however if one swaps the order of OwnsMany and Navigation calls in the nested case (i.e. OwnsMany first then Navigation) things work just fine:...

in my experience it was something like this which broke the rewriter. ```cs public override async Task Test1(bool async) { await base.Test1(async); AssertSql( """ TODO """); } public override async...

note to self: related to https://github.com/dotnet/efcore/issues/33410

standalone repro: ```cs [ConditionalFact] public async Task Repro34849() { using (var ctx = new MyContext()) { await ctx.Database.EnsureDeletedAsync(); await ctx.Database.EnsureCreatedAsync(); } using (var ctx = new MyContext()) { var query...

problem is how we handle Union (SelectExpression -> ApplySetOperation). We try to union two queries: ```sql SELECT p5.BusinessKey FROM Permission AS p5 WHERE (u.Id != NULL) && (u.Id == p5.UserId)...

@InspiringCode a hack/workaround you can use is to make both sides of the union having a matching shapes (in terms of number of entities that they use). You can do...

interesting cases to test out: - scalar - multiple scalars, - non scalar (some function) - identifiers are columns and in places like Distinct we give up if projection contains...