Closed JohnGalt1717 closed 2 years ago
smitpatel
commented
4 years ago This issue is lacking enough information for us to effectively reproduce. Please post a runnable project/solution or complete code listing that demonstrates the behavior you are seeing.
JohnGalt1717
commented
4 years ago I gave you what you need. Pick your favorite database with a one to many and order by the count of the many and select the one. Add a where to the many to filter it. Litterally take my query in the error, and stick it into your favorite database schema.
It's very straight forward and shouldn't need me to write a complete case with a custom database just for your consumption on a basic function.
smitpatel
commented
4 years ago from a in Context orderby a.SubCollection.Count(sc => sc.UserId = ) select a;
This is compile time error.
JohnGalt1717
commented
4 years ago @smitpatel
Yes of course it is! Put in your own where query and dbsets. I gave you sudo code that if you put marginal effort into you'd be able to translate to your favorite database and reproduce the problem.
NetTecture
commented
4 years ago @JohnGalt1717 Do not expect the EfCore team:
The only proper fix for you to work with is to move to Ef 6.4 - way behind technologically (supposedly, for me "works" vs "non works" puts that seriously in doubt), but capable of handling simple SQL without failure for about 10 years now. And available in core 3.1
ajcvickers
commented
4 years ago @JohnGalt1717 We get many requests for help and reports of issues. I typically investigate around 50 cases per week, both on here and from other channels. So while we can make a best effort to reproduce based on limited information, what often happens is that there is some other non-obvious factor involved. That's why we ask for code that we can run--it gives us the best chance of quickly reproducing the issue.
@NetTecture I'm sorry that EF Core is not working out for you. I would love for everyone to be successful using it. I talk to many developers using EF Core, both posting on here, and big customers running serious apps in major companies (which are sometimes the same). Despite how it may seem to you, the feedback we get is overwhelmingly positive. Yes, we have areas we can improve. Yes, some people are unhappy, and that matters to us. But many, many developers are successfully using EF Core in many kinds of applications.
I would suggest that you try other technologies. EF6 is much more stable--if that works better for you, then please use it. Likewise you might consider Dapper or any number of other community projects or commercial offerings. My goal is for you to be successful on .NET, not for you to feel forced into using EF Core.
Finally, please respect the code of conduct and keep things respectful and on-topic to the issue being discussed.
JohnGalt1717
commented
4 years ago @ajcvickers I gave you a reproducible example: Take a database with a one to many. Query on the one, and order by a filtered many's count. It fails. It fails on 3 separate private databases I have with EF Core 3.1 and does not with EF Core 2.2.
Since as far as I can tell, you don't provide a sample or database accessible to take and make reproductions, it is infeasible for small teams to do your bidding and do your job and create the massive reproductions that you're asking for. In this case, even marginal effort would result in you finding the issue. If you want help, then this is a 2 way street. You should have a packaged git hub repository with a sample of a 5-10 entity database that can build on Azure SQL that you provide access to as part of this process and make sure that said database has all cases that you purport to support with EF Core.
Anything less and you're asking people to do your job for you.
As for @NetTecture 's comments, you're blowing off a problem that Microsoft and the .NET team needs to be taking very very seriously and goes to arrogance that is driving people away from .NET and keeping new people from coming in. Let's look at .NET Core 3.x in general and how it's the height of arrogance:
Replace Newtonsoft Json with an incomplete replacement that is only marginally faster (the supposed reason for replacement) that breaks, at runtime, Json serialization/deserialization and doesn't even handle date fields properly. Give backwards compatibility that you know full well is going to result in packages that break very quickly and stuff that won't support Newtonsoft Json anymore that bug fixes aren't back ported to the stuff that did.
EF Core: Rewrite the whole thing for the 3rd time. Cause failures at RUNTIME (See #1) without any way of checking code enmass or even fix code enmass like say the Angular team does between versions. Expect your customers to do the work for you, going through all of their queries and making them all run again from your breakage.
Azure Functions: Don't release a version compatible with .NET Core 3.x until yesterday. A MONTH AFTER .NET Core 2.2 went EOL.
OData: Don't release a version fully compatible with .NET core 3.x even still. And even with legacy routing, again, quickly getting de-supported including bug fixes, it didn't work until AFTER .NET Core 2.2 went EOL.
Note a pattern? I do. Arrogance. It can be summed up as: We have a big team of people with 100% code coverage (you don't, not even close or this bug wouldn't be happening) and thus everyone else should be able to afford to do this work too. The peasants be damned.
.NET Core 3.x release should be a MASSIVE wakeup call for the .NET foundation and the people at Microsoft. Heads should be rolling for this entirely avoidable problem.
What should be happening in emergency meetings right now: ( @shanselman @davidfowl and everyone else you care to tag on this, because this is vital to .NET Core not becoming an elitist waste land)
.NET Core 2.2 support should be being extended until all of the above actually fully works. Every one of them was released with massive missing functionality. That's on the .NET Core team that released an incomplete project and because they didn't admit that they released an incomplete product so satisfy timelines that they promised when .NET Core 2.2 was released and they told us to go forth and use it, they've tried to force people using .NET Core into a version that isn't ready and created a massive lift that cannot be executed on the short time window provided for the switch over.
.NET Foundation should be apologizing for their arrogance and outlining exactly how they're going to ensure that this disaster doesn't happen again. The leadership need to know just how deeply they're losing trust from their customers. (yes, Microsoft, I'm your customer. My company pays you $10s of thousands a year in VS.net licences, Azure etc. in exchange for .NET core to be the best, most complete language to develop against all of that. While .NET Core is open source, it isn't open source as in free, it's open source as in quid pro quo and you need to recognize it. Back in the day you did. If back in the MSDN forum days I had posted this as an MSDN (nach, VS .net) subscriber, I would have had a guaranteed resolution by contract. Now I get "do our work for us" in every single case.
The EF Core team needs to fully admit the complete and utter disaster bred by arrogance that is EF Core versus EF 6. It's only marginally faster, and VASTLY less of a quality product. EF 6 executed almost everything server side. It just worked. EF Core doesn't. It has so many limitations it's a joke. When we set out on this forced "upgrade" to .NET Core 3.1, we quickly started a joke on my small team: Find every use of the group by command. It definitely won't work server side and will now just randomly blow up at runtime. Sure enough, every single group by query that worked in EF Core 2.2 doesn't work anymore. And 100% of the group bys that we do in memory now, worked server side in EF 6 for the record. By setting out in arrogance in the belief that you knew better than the people that created EF 6, you've created a vastly inferior product. Compound that with the arrogance of making your customers spend a day or more writting and providing you with SQL databases to reproduce your bugs in your horrible product, and you have the definition of what I'm talking about.
OData: This is a vital part of ASP.NET Core. Yet apparently the team is vastly under staffed. Worse, to this day you don't understand what you have versus what you're shipping. You're shipping oData as an in-house consumer tool for LOB apps that exposes a database to the internet with REST. While that's a (bad) use case, the core of the product that people use most of the time is $filter, $orderby, $expand, $top/$take, $skip. IE provide a surface area of a list, and control it's shape and size at the client. Your server defines what it's willing to provide, and the client defines what it actually wants from that. That's applicable for all REST and has nothing to do with your EF Surface area and should be completely decoupled from all of the rest. (i.e. odata should have 0 to do with routing unless you want the LOB functionality and the 2 need to be decoupled) This base functionality needs to be integrated directly into the base WebApi functionality of ASPNETCORE and maintained as such. The rest needs to be synchronized with releases of .net going forward and NEVER get into a state where you're forcing upgrades without an upgrade path.
If you're going to make runtime breaks, then you MUST factor in the time it takes to make a tool that will identify all of these runtime breaks. If .NET EVER asks me to go through every single line of code again looking for potential breaks at runtime because of their changes and does so without a tool to find them, I will switch off of .NET entirely and move my company to a product that respects me and my team's time. We're 7 people. We are not Microsoft and we don't have the resources to do your work for you. If Angular can give me a status after completely replacing the entire rendering engine of angular from Angular 8 to Angular 9 (and it would have happily upgraded from Angular 6 to Angular 9 too) and at the end, I can just hit F5 and IT JUST WORKS, WITH 0 BUGS INTRODUCED, NO CHANGES REQUIRED TO MY CODE, NOTHING, then .NET can and MUST do the same. And I should note, that if we move from .NET, we will very likely ditch our $150,000 of Azure spend a year, $30,000 in Office 365 spend a year, and $20,000 in spend in VS.net a year. While I know that's peanuts to Microsoft, you need to be listening to the sentiment here and on twitter. There are a lot of us $200k / year spends that are getting fedup while you reinvent the wheel and treat your customers like crap, or worse, unpaid employees doing your work for you.
Json: Aside from the fact that we're talking single digit improvements in speed with vastly less functionality, you boxed people into a corner. You have to recognize what will happen when you end support for something and provide an alternative. Everything that depends on that legacy tech will switch, and they won't invest the time in supporting the legacy tech. It's already happened with newtonsoft so you're forced into the new to even get .NET Core 3.1 working to replace .NET Core 2.2. You can't just dump out a library that makes .NET Core work with the legacy stuff. That's not good enough, you have to understand that it's everyone else that's the issue and plan accordingly. Specifically, cyclic re-entrance needs to be handled, so does dates, and so does providing default Settings before Json is ready for prime time in .NET Core 3.1)
NEVER, EVER EOL a version when you don't have a viable replacement for it.
If you have to induce work in people using your stuff because you have no other choice, not be arrogant about it. Apologize, and be honest. Don't brag about the speed of .NET Core 3.1 when you've foisted over 300 (wo)man hours of labor on a 7 person team and counting because of your (bad) choices, to say nothing of the risk my company has because of your decisions now that we're running EOL .NET Core 2.2 in production because until last month we couldn't even see a path to a working product with .NET Core 3.1 and had to wait knowing that we were risking the entire company on one security vulnerability that wasn't patched. The Windows team doesn't leave people high and dry when ending a version, yet the .NET Core team is happy to and brags about it.
If this isn't the place for this post, then tell me where to post it, because I'm not alone. Twitter is rife with .NET isn't inclusive, .NET is hard,, .NET is overly complex (@davidfowl just posted this) because everyone is putting Interfaces, and stuff on everything and they don't need to. You know where all of that comes from? .NET guidance from Microsoft and the .NET Foundation. You're failing because of arrogance. You need to read the poem IF. Walk with kings! But you've can't talk with the common man anymore. (and I haven't even gotten into the disaster that is your consumer UX/Frameworks that are easily fixable, but everyone wants to be technically perfect and no one wants to build what developers are demanding.)
JohnGalt1717
commented
4 years ago Sorry, enter cause close for some reason. Reopening
NetTecture
commented
4 years ago I would add to that that the lies have to stop. Sorry to be blunt, but with the results of my attempt to move from efcore 2.2 (which btw ONLY worked because we had time to wait and loaded prefiltered by tenant data into memory THEN used LINQ to objets because EfCore 2.2 was HORRIBLY broken with core functionality) to 3.1 and finding that now the one serious issue making global query filters totally useless works, but standard queries do not work and the most simply projection case do not work because someone decided that standard LINQ is not something EfCore should support anymore...
... I have to tell you flat out that
"I talk to many developers using EF Core, both posting on here, and big customers running serious apps in major companies (which are sometimes the same)"
Means you either work with the most trivial developers I have seen in 30 years that only use the most basic functionality of EfCore - i.e. simple select with simple where clause, OR you are a liar because I see pretty much every business class blowing of. And I can not imagine a large team working on an application that does not ever use:
And yes, it is that basic. The example @JohnGalt1717 gives here is trivial also. And it is a regression, of which there are tons of.
What is totally insulting on that is not that there are bugs, but that it seems both management and the team are utterly incompetent in fixing them and providing a platform that is professional by standards of the last 10 years.
Look at the number of bugs fixed for 3.1.2 - ZERO. Null. Nada. Obviously no bugs are critical enough (like bad SQL generation) to be fixed. Instead we now are told - again - to wait for the next great version, 5.0, which shall come in November. Which we were told for 2.2 (wait for 3.0), then for 3.1 (we did not make it into 3.0, the new sql generation comes in 3.1). Well, it did come - more buggy than before and with critical core functionality removed, likely because some intern was over his head working with things like projections. "Go fix your code again and rewrite all queries, even if that is not possible beause hey, we only work with hello world level code here" is not professional. I now run 3.1 with EfCore 2.2.
If you guys would have fixed EfCore 2.2 idiotic bug with global query filters ONLY (instead of breaking another half dozen things, some of them on purpose, I would have been happy. As it stands now, we are told to f*** off and wait for Novembe after having been told the same for 2.1, 2.2, 3.0 AND 3.1 (Which was supposed to fix the bad sql). And then there is this amazingly incompetent "we are not comfortable rolling out bug fixes as hotfixes". What about rolling them out in a 3.2 release with a proper preview cycle so "not comfortable" can be handled in a prerelease? Not the MS way? Well, arrogance HAS a name now because it IS the way Blazor does it - a 3.2 release planned for May. Obviously it is possible for Microsoft. Except for whoever is in charge of EfCore - which seems to think that a useless product is good enough and then goes on telling that LARGE customers OBVIOUSLY do not use the product enough to get hit by any of the hundreds of reported SQL based bugs.
No sure who is in charge here, but quite some people should be fired, I agree with @JohnGalt1717
Well, tomorrow I move back to Ef and then work around the libraries that automatically use EfCore now. At least Ef does work still. What I will missing are global query filters, but you know what? SOMEONE ELSE TOOK CARE OF THAT - there is a free open source library adding them to Ef.
Pilchie
commented
4 years ago Hi @JohnGalt1717 and @NetTecture
I'm the Engineering manager responsible for ASP.NET Core, Blazor, Windows Forms, and Entity Framework (both Core and 6). I'd be happy to discuss the issues you've been seeing in more detail. Let me start by discussing some of the issues/constraints mentioned in this thread from my perspective. Hopefully with that in mind, we can have a more productive conversation about ways we can do a better job.
Given the above, I'd be open to constructive suggestions about improving our process in email at kevinpi@microsoft.com.
NetTecture
commented
4 years ago @Pilchie Well, here is the point as I see it. Ef Core - EVERY version so far - is a piece of shit with features advertised that did not work. Period. The best version so far was 3.0. 2.2 had SERIOUS issued with Global Queries not working on many standard cases, so that feature was useless. 3.1 decided to rip out anything worthwhile and break compatibility and STILL does not fix the SQL generation. You are risk averse? This is rotten food. It is not edible. I have yet to meet ONE customer project of non trivial complexity that is not trying to work around the most basic limitations. Your process sucks - typical waterfall like in big companies and run with a team that never has to eat their own food. I am out - odata got the curve well enough, efcore is so broken I either stay at loading whole tables into memory (broken global queries blowing a "simple" select join other table in 1:1 relationship if that is filtered out") or get all kinds of bugs because someone decided LINQ is not something to support. The laternative is Ef - yes, I miss global queries, but there is a third party extension that adds them. Whatever release cycle you have is ivory tower stupid. You have no product worth shipping. You waste time on useless features for small scale databases (migrations i.e.) while the basics are not working. Now, I am not saying that "migrations should not exist", but if you can not get the base product working, maybe your engineers should focus on that instead of bells and whistles on a car without engine? I Just spent a week trying to move from 2.2 to 3.1 and I am literally done - I get an amazing amount of stupid errors all around "well, w do not do client evaluation". This in itself is not bad - except a filter property by value is not client evaluation. EXCEPT if you are EfCore, then the little "project table into business object and filter that" - which perfectly worked so far, server side mind you - blows. Well, there you go. Works up to 2.2 (not tried in 3.0 because that one has no support long enough, you know). Now the stable 3.1 branch is so broken it can go an do itself.
Repro: Nice from you, you blow all the work on us. See, if there would be a repository you can fork with a framework that works and where you plug in a repro - nice, this may work. If I can put up an empty repro case without any code from me in 5 minutes then I will do it, THEN add my code. But what your engineers take 20-30 minutes per case is hours for anyone outside because there is not even a database and your people dump everything back unless it runs on a non specified machine. And IF we provide it, the typical answer is "wait for half a year with your product that you have to ship next month, because we are risk averse and generally it works fine in Hello World". Nope, not wasting my time on that. Particularly not when there is a working product - Entity Framework - that actually does what it is supposed to do. I am with @JohnGalt1717 here - part of the problem is that we see no progress in any timeframe that is even mildly relevant. I get paid by a customer. A bug report that is possibly fixed in a year is not helping him to ship his product, so why waste time? This is so detached from the customer - last time I saw something like that was in Odata which for years refused an IN query statement because you could also write 20 single conditions in the URL.
Blazor: Seriously? Yes, but their approach WORKS. You approach does not, particularly because you do not even TAKE feedback. 3.0 had previews, all nice. 3.1 was what - 5 weeks fast job without real feedback and previews AND RIPPING OUT SIGNIFICANT FUNCTIONALITY WITHOUT EVEN ASKING CUSTOMERS. It does seriously not get more stupid than that. The first time I saw all the limitations introduced was in the release notes - and I was reading up on what is going on. People where surprised. Like when Blazor release suddenly only runs on ARM processors because of last minute change.
"Fixing issues in servicing versus major versions Our general bar for servicing fixes is major issues blocking a significant number of customers without a workaround." Be happy you work for microsoft. That statement would get you fired in my teams without recourse. See, "product with core functionality working stable and well tested" is how you build stuff that is not blocking a significant number of customers, and your test cases at least are broken. Like a Lamborghini of old that may start to burn in the showroom because sometimes someone forgets to put in all the fuel pipes (no, seriously, they had a 10 page checklist for the dealers once and fuel lines where one item). If I can break your ORM with a simple group by then this is baseline. On top, your test approach makes sure that you have to live in fear of breaking changes. There should not even be an EF Core 5.0 release planned unless you have SERIOUS changed planned - the number should mean nothing. Instead you should target 2-3 releases a year with permanent public previews. Let me get this week's version via nuget. You know what? I write backend code all day. 98% of that uses Ef. If you make it easy enough for me (nuget preview packages) I normally would branch, grab last build and run MY test cases against this. And then if bugs actually would be worked on (and I have bugs back from 2.2 that now are delayed for 5.0) then yeah, maybe I even spend the time to make repro cases. But I do not see fixes. What I see is 3.0 delaying the better SQL generation to 3.1 and then 3.1 coming with core functionality removed because - no fucking idea. I can not get a state of mind where this is even borderline non idiotic. I do not have time to make repro cases for a bug that blocks me from shipping and gets delayed 2 MAJOR versions and more than a year down the road. What I need is a product I can use, and EfCore is not it in ANY of the past versions.. You know who does not have this problem? Angular. C#. Typescript. I still have to find a 3.1 release analogy there creating brutal changes in the last release and then wondering people are not happy they have to rewrite all the code. Btw, Odata is a special case (they f**** up epically, but they managed a fast temporary release and seem to work finally on a more integrated approach). ASP.NET worked. EfCore - can you imagine I went to around 85% red unit tests in my backend logic? That is after 2 days fixing projection based logic. Yes, that bad. But according to you I do not deserve a fix. See, I do have a workaround. Stay with 2.2 and load always the whole table into memory then use LINQ to Objects to filter. Performance is awful, but it works - so workaround. Obviously without support as 2.2 is out of support and 2.1 is way more primitive. But still, workaround.
The fact that you broke a TON of functionality that works perfectly in 2.2 shows that you are not having even an idea of proper test cases. Come on, #19830 is not that complex and a standard case. Same with #19079. Your approach basically is waiting for dead people to be reported before fixing the breaks that are broken on all cars you ship - heck, as long as people drive slow and use the handbrake there is a workaround, let's not fix it. Overcomplex SQL - THAT Is not critical. A simple group by not working is. Returning related objects without include because they are in the cache is (because it may expose hidden data to an ourside service).
The way I see it, you are so much underwater you have no chance to get back up without serious changes, more resources and a focus on quality. More resource can mean a better framework for repro cases, but you must get your release cycle in order. Me, and I am sure many others, will not spend time for repro cases that will not see the light of the day in a relevant timeframe. Heck, I am not even going to try to make a pull request - why should I? If I fix something, it will show up in half a year or later. Nothing to gain. This may actually be the core issue here - there is no reason to support this project in any way because fixes are not making it back to the people writing them. Yeah, fear is a bad co-manager. Why should I spend a weekend fixing a bug - if the fix is totally useless for me?
NetTecture
commented
4 years ago That, btw., was my last post here. I am now spendig the evening reproducing new model classes for Entity Framework 6.4. I may still use EfCore, but only becasue some third party libraries hook into it for some tables (OpenIddict). I will keep myself updated, but the next time I see EfCore being something to even look at is after summer when the 5.0 release is approaching a phase where it is worth for me to spend some serious time moving (again) from Ef to EfCore to see whether things are fixed.
JohnGalt1717
commented
4 years ago @Pilchie Emailed.
Pilchie
commented
4 years ago @JohnGalt1717 - I'm not seeing it yet. Can you verify what address you sent it to?
JohnGalt1717
commented
4 years ago @Pilchie Try now. Fiddler was running on my machine which eats every windows store app so my email didn't go out until I realized what was blocking everything.
Pilchie
commented
4 years ago @JohnGalt1717 got it now, thanks. May take me a bit to respond though.
@NetTecture I'm sorry you feel that way. I'd be willing to continue the conversation either on a new issue, or in email, but I think we've polluted this issue thread long enough. Let me know if you'd like to continue.
sandord
commented
4 years ago Albeit off-topic, I'd like to spend a moment here to hearten the EF team a bit. Their job is a tough one and I think the above negative sentiment is very unfair and not contributing in any constructive manner. Whatever problem may exist, it should always be possible to have a mutually respectful conversation about them. @Pilchie's response is a perfect example of (an attempt to make) such conversation in my opinion. Keep on the good work guys!
ajcvickers
commented
4 years ago @sandord Thanks for your words. I really appreciate you taking the time to share that.
ajcvickers
commented
4 years ago 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.
JohnGalt1717
commented
4 years ago Given that:
This should not be closed and goes once more to the root problem.
NetTecture
commented
4 years ago @JohnGalt1717 Have you not realized by now that the EfCore team is run by a dilbertesque incompetent manager and is absolutely NOT doing any dogfooting and using their own product and living in an academic bubble?
You must prepare a repro case for the most simple scenarios because no, they never test anything in the real world. I really have to look up all their names ones - i can swear they all are junior developers, at least they behave like that. They also totally lack the understanding that most of the issues I see them have are the result bad quality control AND release cadence. Well, you can bring a bug to Microsoft, but you can not make the donkeys drink, so to say.
Anyhow, you can head over to https://github.com/NetTecture/EntityFrameworkCoreIssues
and fork that repository. It should be quiet easy to set up a test case there, though you likely need to add another class and registering the relationships there. Given that this is another pre-execution issue based on their lobotimizing of the query graph processing since 2.2, you do not need a functional database for it. Which means you should be able to set up a repro in an hour most. I am going to add to this repository with every bug I discover. You have to proove that they broke it, because they NEVER use the product for anything except trivial sql, it seems.
The above repository is what I will use now to make easy repro cases that work on 2-3 versions to show how they bother the most basic things. You will also see that #19999 has a repro there, which goes quite along the same line. We will see whether this gets fixed or not. This reminds me so much on the disaster that Ef class c was pre version 4, except this time there the rest of the world has moved on.
It is people like @sandord who demonstrate the total destruction of values such as "quality" and "working product" that today's developers do accept. I grew up with "if you work as a cook and all you do is food that makes people vomit, you suck". not with "oh, you poor professionals work under soo much pressure and people are sooo unfair to expect your product not to get broken between releases". Your statement was absolutely correct about the attitude. But without repro you will not change it.
Pilchie
commented
4 years ago @NetTecture I've hidden your comment as abusive.
This repository will not accept behavior that is not respectful and inclusive of all members of the community per it's code of conduct. We'd like you to be a member of the community, but your current comments are offensive and will not be tolerated, regardless of whether they have technical merit.
JohnGalt1717
commented
4 years ago @Pilchie I sent you my feedback 15 days ago now. I have heard nothing back. This problem continues to get worse as we discover more and more run-time broken queries that worked perfectly fine with full server side evaluation in EF Core 2.2 and there has been absolutely 0 response from the EF Core people or the entire .net team into this horrific disaster that has been created by the arrogance and complete disrespect for your customers.
When are we going to see a public statement from Microsoft and the .NET leadership on the disaster they created forcing upgrades that weren't ready after making false promises about .NET Core 2.2 and when .NET Core 3 would be ready?
I still don't have released working code for oData, EF Core just keeps getting worse and worse in our testing, Azure Functions was JUST finally released for .NET Core 3, and Json is still broken in one of the most common cases, javascript clients sending numbers as strings not being deserialized properly into the target classes to name just a few.
Meanwhile Damian Edwards is busy on Twitter mocking Node for the node_modules folder that actually fixes a ton of bugs in .NET dependencies that created the binding redirect disaster that wasn't solved in .NET core, just ignored outright and Azure Functions breaking endlessly to the point where its basically unusable as a component in a project unless you use javascript instead of .NET.
And that's just one highlights of the arrogance of the .NET leadership on Twitter while .NET Core usage has flat-lined and Windows development is dying. No one wants to admit it but Panos Panay has exactly one opportunity to save Windows and then Nadella is going to pull the plug and become the IBM of the cloud. But hey, let's brag about what we've done, treat our customers like crap and show complete tone deaf arrogance instead of working hard to earn our customers back. Yes your stock is way up. That's exactly what happened to IBM when they first pulled the plug on consumer products. Look at them now. 25% of their highs. Meanwhile "The language of Azure" is a disaster and the leadership is so busy preening in-front of the mirror that they can't see what they've done.
So when can we expect a substantive response that actually addresses this instead of offering platitudes wrapped in more arrogance?
Pilchie
commented
4 years ago @JohnGalt1717 - I've hidden your most recent comment as off-topic, as it offers no technical information related to this repo.
For your email, I've provided it to our leadership to decide if and how they want to respond to it.
JohnGalt1717
commented
4 years ago @Pilchie This original issue still hasn't been addressed, hasn't even been attempted to be reproduced and was summarily closed without any attempt to fix this regression. So I'd say my comment is very much on topic.
Pilchie
commented
4 years ago @JohnGalt1717 As I see it, you were asked to provide a concrete repro, and that still hasn't happened.
JohnGalt1717
commented
4 years ago @Pilchie I did. This is a trivial repro. Order by the count of a whered sub child collection. If you read the top, you can take ANY parent child relationship, filter the child, and take the count and order the parent by it and volia, it causes the error. But I was told to spend hours reproing and creating databases (without a template from your team!) instead of them taking the basic time to repro the issue.
When asked if they even attempted to repro it all I got was deflection without an answer, thus I didn't bother putting more effort into creating a complete repro from scratch since your team hasn't got a template for doing this and I don't have an hour to waste doing their job for them if they haven't even attempted to reproduce it themselves.
Note the common theme here. This kind of behavior chronic within this team: make your customers do your work for you.
vslee
commented
4 years ago Just some background: the EF Core team is 6 ppl, which is small, essentially the same size as your own team, as you mentioned in your comment https://github.com/dotnet/efcore/issues/19830#issuecomment-583734670. EF Core is a complex product with over a thousand issues in the backlog. Thus, for each product cycle, they have to go through a painful triage process of figuring out which issues to tackle for that version. There are many of us users watching and hoping for the issues which are important to us to be included. Since they can only get to a fraction of them each cycle, it would make sense to maximize the time they can spend working on these issues. I would actually prefer that the EF Core team make it an explicit policy that they don't investigate issues withouta repro. This is in fairness to other users who do create one. In terms of creating a repro, the pseudocode you posted is not a concrete repro. If the repro is as trivial as you say it is, then you can probably create a concrete repro in 5 minutes. On the other hand it would probably take the EF team an hour or more to try and create the concrete repro. After that effort, their efforts might still not reproduce the bug. The reason for this is because a lot of details are lost in pseudocode. I think we can all agree that we would rather the EF team be spending their limited time on the issues themselves, rather that trying to create concrete repros. For a template of creating concrete repros, take a look at the ones I created in my previous issues: https://github.com/dotnet/efcore/issues?q=is%3Aissue+author%3Avslee+is%3Aclosed As you can see, they can be very simple pieces of code. And for you, would probably take only slightly longer than writing the pseudocode.
JohnGalt1717
commented
4 years ago @vslee then they should have taken that into account instead of rewriting EF for (at least)the 3rd time while making it worse not better. (There's no metric where EF core 3.1 is better than EF core 2.2 for the end user. It isn't faster in aggregate, has more bugs, and is less functional while inducing more memory usage, more bandwidth usage and significantly more code to work around all the queries that uses to execute server side that are broken now.)
And judging by the comments from those 6 devs, it isn't even less brittle now as evidenced by the fact they're still terrified to fix bugs for fear of breaking stuff.
Sorry but I'm not going to feel bad for a trillion dollar company that makes over $100,000 a year from my company alone. Especially when they make bad decisions and inflict the consequences of those bad decisions on their customers.
If Microsoft doesn't want .net to become as irrelevant as Windows is quickly becoming (it's basically a shell for running a web browser at this point) they need to invest and stop treating their customers like this.
I'm off for 3 days and the CEO of our company wants an answer Monday as to if we're pulling the plug entirely on Microsoft and moving to a company or companies that respects us. That means .Net, azure, office will all be replaced within this calendar year.
As it stands right now, the answer is going to be yes, let's leave and encourage our partners to do the same (our partners are significantly larger than us but depend on what we do and are watching our decision here very carefully).
I've given people at Microsoft 15 days so far and 450 hours of development to work around this disaster and still haven't gotten anything but excuses and claims that people are loving EF core 3.1. I did a search and couldn't find anyone saying anything significantly positive to backup the claim.
There's thousands of complaints however here and in blogs.
And that's just the issues with ef core. Odata, json, and azure functions are all in similar states of disaster making major regressions from .net core 2.2 with no hope for repair until at least November.
vslee
commented
4 years ago I can't speak to the technicals of the 3.0 changes, but breaking changes are usually unavoidable after such a large overhaul. Think about the recovery period after someone gets major surgery.
If you've already spent 15 days and 450 hours on this, what's another 5 minutes to create a concrete repro?
JohnGalt1717
commented
4 years ago @vslee more like an hour that isn't needed because no one bothered to even try. Why would I do their jobs for them?
There has NEVER been a version of .NET since .NET 1.0 that actually had run-time bugs introduced that weren't just bugs that were fixed between major versions. In .NET Core 3.0 there are several dozen of these. It's as big a change as .NET Full to .NET Core 1.0 (with the same loss of features too).
But the difference is that no one forced you to migrate from .NET 4.6 to .NET Core 1.0, 4.6 was still supported. .NET Core 2.2 was represented as a reasonable short term upgrade because .NET 3.0 would be fully compatible and straight forward upgrade by Scott Hanselman and others on stage and in blogs. And then they terminated support before .NET 3.1 was released, before odata was ready (still not ready), before Azure Functions was ready (ready Feb 8th 2020!), with EF Core 3 generating run-time bugs and causing a loss of all of the performance 3.x promised and then some because of the massive loss in complex query capability that forces calculations and groups to be done in memory in your api instead of on database where it belongs. To say nothing of Json Serialization which is a complete mess where the most basic things that Newtonsoft.json supported don't work, all to end the dependency hell and for a marginal speed increase that could have been done by simply renaming Newtonsoft.json as System.Text.Json change the version # and adding Spans everywhere and we wouldn't have lost all of the basic functionality that is missing. (and no, if you' pay attention you'll note that it isn't really possible to just keep using Newtonsoft.Json because most 3rd party libraries forked and .NET Core 3 versions use System.Text.Json and .NET Core 2 versions use Newtonsoft.)
It's basically impossible to migrate from .NET Core 2.2 to .NET Core 3.1 without treating it like a complete lift and shift rewrite like we did 2+ years ago from .net full fat to .net core 2. My team has touched 87% of our code between Json, replacing oData that still isn't ready, and EF Core 3. That's about the same percentage of code that had to be altered going from .NET Full to .NET Core 2.
And we still have show stopper bugs that we can't work around like Json not being able to deserialize string numbers into number fields in classes which work fine in Netwonsoft but breaks in System.Text.Json at run time from 3rd party clients that now have to rewrite code to work with our API to fix Microsoft's problems. (there's a work around, but it only works serializing not deserializing, and yes there's lots of good reasons, including precision as to why companies do this)
So much for Scott Hanselman's (and other's) promises that we bet our company on. Meanwhile we're out of support as a result with no security patches risking our entire company every day.
At this point I've been tasked by our CEO who's watched the insulting commentary from Microsoft devs at all levels, with making a decision by Monday if our company will be better off risking .NET 2.2 for now and rewriting our API in another language (and if so, what) made by a company or companies that respect their customers. And if we do that, provide a plan to remove .NET, Azure, Office and everything else we use that is Microsoft within the next 12 months. (About $104,320 US worth of lost revenue in total plus partners that end up agreeing with us that do the same and the 15 or so customers (including 2 major federal government projects) totaling another $17 million or so in revenue for Microsoft that I consult for on tech decisions like this, that will now be advised that .NET and Azure is not a safe platform to build a company upon because you risk being exposed to massive security vulnerabilities without support based on miss-information while the highest levels of the company dismiss you and arrogantly brag about what they did.)
Since I gave them 15 days to today and now another 6 to Monday to respond, I'm going on vacation and thinking about whether this is worth it, or if there's a better path. I get to spend my evenings test coding instead of relaxing, coming up with a viable alternative, or a path forward where this never happens again with .NET. Since that requires people at Microsoft to actually step up and take responsibility for their actions which they clearly aren't willing to do, my path sadly appears clear. I've spent 20 years of my career in .NET and another 5 before that in VB being one of Microsoft's biggest advocates. To be betrayed like this is shocking to say the least.
vslee
commented
4 years ago If it takes an hour for you to reproduce, then it's not trivial like you first stated. Which means that it's probably near impossible for someone else with a incomplete picture to reproduce. I suppose if they had one of their engineers dedicate their entire day to doing trial and error, they might be able to come up with something. But why? When you could so much more easily reproduce it on your end. They might even spend the whole day doing that and still not come up with it. Wouldn't you agree that the time is better spent on them actually fixing one of the known issues?
JohnGalt1717
commented
4 years ago 30 seconds to write the offending code, 30 minutes to setup the context, make it load, put the DB in azure, 10 minutes to put the code in github and write the description etc.
Ie all of that save the 30 seconds should be predone by the EF core team.
Pilchie
commented
4 years ago I'm locking this thread to prevent further unproductive conversation.
In the past you could do the following and it would evaluate server side no problem without any errors:
from a in Context orderby a.SubCollection.Count(sc => sc.UserId =) select a;
It now fails with: EF.Property called with wrong property name.
Using Where instead of a filter in the count fails with the same issue. Using let to get the count and then ordering by it also fails. Using select of the values, then ordering by those also fails.
There's no discernable way around this and is a major blocker because we need it to evaluate server side properly.
EF Core version: 3.1.1. Database provider: Microsoft.EntityFrameworkCore.SqlServer Target framework: NET Core 3.1 Operating system: Windows/LInux. IDE: e.g. Visual Studio 2019 16.3/vs code, command line, unit tests.