Wasted two hours to end up finding out EF Core had a bug :\

Next time better blame Microsoft before blaming my code lol

https://github.com/aspnet/...

2 hours ? Wow, you have way more patience then me.
I would’ve created a stored proc just for this case which takes skip and take values as parameters with a comment

-- TODO : Use skip / take of EF when it works

@NoToJavaScript what made suspect my code is the navigation property I needed was read from database in another function to later find out that it her function didn't use skip and take, that's when I thought to check GitHub 😅

@gitpush For now EFCore is soo fucking limited. I use it in one of the projects (Commercial, in production) and already have problems.
I guess, I’ll stay on EF6 for the next couple of years.

@NoToJavaScript true, but I want to use Linux as hosting, might look into other languages, tho not sure which is the best to check, I'm exploring golang tho

@gitpush I’m using it with Azure Functions. So basically, I don’t even know on what OS it runs (I think it’s called Azure fabric, but not sure).
I understand for Linux hosting ;p .net core seems (I didn’t test) to run pretty well on Linux

@NoToJavaScript EF6 is part of .net framework and can only run on windows/windows based OS

As for dot net core it runs pretty well but still too young for all cases

@gitpush Sadly, I know :(

Same thing happened with one of my co-worker who had chosen this EFCore for one of his .Net project. The pages were being rendered in 30 seconds. He also found out about this bug but only after a week of development work. Had to reimplement everything again..

@themissingbrace 30 seconds for a page how is this possible?
I don't use Asp.net core, but I do have an API that spits out 1500 record in one second when requested from an online server, I know 1500 is small but never seen that much of delay in EF Core unless either of the following is not taken care of:

1. Eager loading: results in loading all data from tables that have relations
2. Fetching all columns when only few are required
3. Use IEnumerable for queries when it must always be IQueryable or all data will be processed on client side (typically server instead of Database)
4. Not that much of boost but compiled queries and DBContext pooling does reduce time fetching data
5. Using many "Include" in one query results in multiple trips to database for fetching data