PomeloFoundation
EF Core 10 support
We will use this issue to track the progress on supporting EF Core 10, including its previews.
.NET 10 RC 1 has been released. We expect to upgrade the entire codebase to support .NET 10 and require a preview package of version 10.0.0.
Is it possible to first build an early preview version in pomelo-nightly that supports EF 10 RC and above?
@witskeeper you can upgrade your entire codepase to .NET 10 but stay with EF 9, in case you're not aware. EF is a separate component should not be blocking a .NET upgrade.
@witskeeper you can upgrade your entire codepase to .NET 10 but stay with EF 9, in case you're not aware. EF is a separate component should not be blocking a .NET upgrade.
Yes, that works. Thank you for your suggestion.
Hello @lauxjpn,
What is the plan for EF Core 10 support ? I only request some visibility about your plan.
I know EF Core 9 continue to work but some new libraries/versions depends on the EF Core 10 (Core Identity for example).
Thank you for all your hard work!
Yes, there will be an EF Core 10 compatible version soon.
The plan is to have a working upgrade out by the time .NET 10 goes GA. Whether this will already include all new EF Core 10 features or just a subset is not clear yet.
But whatever worked in 9.0 should still work in 10.0, since we do not publish anything without ensuring that all existing tests still work.
I will open a PR for the upgrade within the next few days. It can be used to track the progress of the initial release (same as in the years before).
Sorry to push, but .NET 10 got released yesterday. Is there any ETA for a new version of Pomelo EF Core?
Using Microsoft.EntityFrameworkCore 10 with Pomelo.EntityFrameworkCore.MySql 9 does not work (I tried), it causes the following exception during application start:
System.MissingMethodException: Method not found: 'System.String Microsoft.EntityFrameworkCore.Diagnostics.AbstractionsStrings.ArgumentIsEmpty(System.Object)'.
at Microsoft.EntityFrameworkCore.Utilities.Check.NotEmpty(String value, String parameterName)
at Microsoft.EntityFrameworkCore.Utilities.Check.NotEmpty(String value, String parameterName)
at Microsoft.EntityFrameworkCore.ServerVersion.Parse(String versionString, Nullable`1 serverType)
at Microsoft.EntityFrameworkCore.ServerVersion.Parse(String versionString)
at Microsoft.EntityFrameworkCore.ServerVersion.AutoDetect(String connectionString)
For now we will stick with version 9.0.8 of Microsoft.EntityFrameworkCore, while upgrading everything else to .NET 10. That seems to work so far.
Since my application uses the new .NET Identity in .NET 10, I get the following compilation warning:
warning NU1608: Detected package version outside of dependency constraint: Pomelo.EntityFrameworkCore.MySql 9.0.0 requires Microsoft.EntityFrameworkCore.Relational (>= 9.0.0 && <= 9.0.999) but version Microsoft.EntityFrameworkCore.Relational 10.0.0 was resolved.
It appears that both .NET Identity and Pomelo.EntityFrameworkCore.MySql have a dependency on Microsoft.EntityFrameworkCore.Relational... and only one can be the winner.
I apologize if this is a naive question...
I see no completed activity on the v10 Milestone (https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql/milestone/64), no git branches, nor any git tags for v10. I was hoping to pull it down and see if there was anything I might be able to help with...
I'm sure this being worked someplace where the community could get involved, but I'm not seeing it. Can you point me in the right direction? Thanks!
Quick update: The basic EF Core 10 upgrade is done and I am fixing/updating the tests. Currently, 703 of 30480 tests are still failing. So expect a stable EF Core 10 compatible preview in the upcoming days (once all existing tests are green again).
For those who are unaware, EF Core 9 & Pomelo 9 are compatible with .NET 10 (but Pomelo 9 is not compatible with EF Core 10). See our compatibility matrix.
Does it support connecting to MySQL 9.0
You asked this in 3 separate tickets. I don't want to be rude, but at least just try it out and try to report findings as much as possible if it doesn't. But this is not really helpful or "nice" at all.
Well... it's been a couple of days and there is no new commit on the pull request and no status update here. Do you have anything to share? Thanks for your work on this. I know about the ef 9 workaround but it is not possible for us because we have a "framework" on our side that is shared among multiple applications and it is already updated to .net 10 including ef. We have one application that connects to a mysql database and we can't update that application. Thanks.
Well... it's been a couple of days and there is no new commit on the pull request and no status update here. Do you have anything to share? Thanks for your work on this. I know about the ef 9 workaround but it is not possible for us because we have a "framework" on our side that is shared among multiple applications and it is already updated to .net 10 including ef. We have one application that connects to a mysql database and we can't update that application. Thanks.
Whomever built your framework could possibly downgrade back to .NET 9 for the time being. It shouldn't cause any issues for your clients that are on .NET 10, and there isn't, to my knowledge, any additional MySQL version number compatibility in 10 vs 9.
Quick update: The basic EF Core 10 upgrade is done and I am fixing/updating the tests. Currently, 703 of 30480 tests are still failing. So expect a stable EF Core 10 compatible preview in the upcoming days (once all existing tests are green again).
For those who are unaware, EF Core 9 & Pomelo 9 are compatible with .NET 10 (but Pomelo 9 is not compatible with EF Core 10). See our compatibility matrix.
Is there anything we can do to support you with this (as just counting "failings" won't let us know what to adjust/fix) .. ?
Btw, I still think this is great work, and there’s no need for pressure to drive it.. ;-)
Well... it's been a couple of days and there is no new commit on the pull request and no status update here. Do you have anything to share? Thanks for your work on this. I know about the ef 9 workaround but it is not possible for us because we have a "framework" on our side that is shared among multiple applications and it is already updated to .net 10 including ef. We have one application that connects to a mysql database and we can't update that application. Thanks.
You can try mysql.entityframeworkcore-10.0.0-rc, it surport ef 10.0
@lauxjpn Would it be possible to get a status update? Just so we have an idea how things are going. It is ok if it takes time, but it would be nice to know.
Well... it's been a couple of days and there is no new commit on the pull request and no status update here. Do you have anything to share? Thanks for your work on this. I know about the ef 9 workaround but it is not possible for us because we have a "framework" on our side that is shared among multiple applications and it is already updated to .net 10 including ef. We have one application that connects to a mysql database and we can't update that application. Thanks.
FWIW, adopting a new major version (even an LTS one) before all dependencies have caught up can lead to situations like this. BTW, working on a non-LTS version (formerly .NET 9.0 if I understood well) in a professional context is generally not recommended, unless you have specific requirements or needs.
BTW, working on a non-LTS version (formerly .NET 9.0 if I understood well) in a professional context is generally not recommended
Ou.. think Stephen Toub (partner software engineer at .NET) doesn't know that as well ;) https://www.youtube.com/watch?v=6Ixv-XmK8YY&t=2420s
BTW, working on a non-LTS version (formerly .NET 9.0 if I understood well) in a professional context is generally not recommended
Ou.. think Stephen Toub (partner software engineer at .NET) doesn't know that as well ;) https://www.youtube.com/watch?v=6Ixv-XmK8YY&t=2420s
Ofc fair point regarding the runtime stability itself, and Stephen Toub is obviously right about the performance gains.
However, the remark was more about the ecosystem: adopting a new major version (STS, or even further ahead like .NET 10 as mentioned above) often means facing friction with third-party libraries that haven't caught up yet. As evidenced by this very thread, the bottleneck usually isn't the runtime itself, but the dependencies.
However, the remark was more about the ecosystem: adopting a new major version (STS, or even further ahead like .NET 10 as mentioned above) often means facing friction with third-party libraries that haven't caught up yet. As evidenced by this very thread, the bottleneck usually isn't the runtime itself, but the dependencies.
I don't see any relationship between this thread and the STS/LTS distinction; every time a new version of EF comes out, there's a bit of a lag - sometimes longer, sometimes shorter - before 3rd-party providers like this one release the corresponding version. This has nothing to do with LTS or STS, and is just a normal state of affairs.
Since the recent .NET policy change for STS versions to be supported 2 years (link)- until the same date as the existing LTS version - there's even less version not to use STS versions.
While I understand the eagerness to switch to the latest (EF 10 in this case), I'd encourage everyone to simply exercise a bit of patience and not continue posting here, asking for updates and/or demanding progress reports. People aren't paying for this work, and the maintainer has other things that need to get done - the new version will land when it lands, as it has every year since this provider has existed.
While I understand the eagerness to switch to the latest (EF 10 in this case), I'd encourage everyone to simply exercise a bit of patience and not continue posting here, asking for updates and/or demanding progress reports. People aren't paying for this work, and the maintainer has other things that need to get done - the new version will land when it lands, as it has every year since this provider has existed.
@roji I genarally agrees with your point, but the reason, why a lot of questions pubs up, is that the progress and greate work is not visible to people.
I don't care about that we are 700 or so failing tests away from a working rc. I as a developer want to see, which tests are failing in github actions, so I can make a rational decision if those failing tests are of any relevance to me or I have any knowledge I could bring that might help solve the problem.
So it's really hard to help in any way. Just put out a branch with ef10 migration in progress, so everybody can see what is working and what is not, which tests are failing and which are not.
Maybe some people have time to do the niddy griddy work of fixing some of the tests. There is no need for the project to be bound by a single person doing all the hard work. This is what PR's and code review are for :-)
Sorry for the long rant, but open source is not a one-man show if the environment is to thrive.
@renemadsen what you're saying works nicely in theory, but in practice, this specifically is a complicated provider that requires quite a lot of internal EF knowledge; it's very likely that this isn't blocked by simple "nitty gritty" test fix work, but rather by actual serious work that requires a deeper understanding of the project (otherwise version 10.0 would have been out by now).
I'm very much a believer in open source, but pretending that outsiders who have never contributed will be able to just jump in and fix failing tests in the push to 10.0 - things don't usually work that way. Contribution to deep, complicated projects such as this one require regular work over a significant period of time, during which the contributor gradually becomes familiar with how things work, and during which the attention of the maintainer is required to guide them, review PRs, etc. If someone is interested in getting involved in the provider in general, that's great and they can absolutely do so - gradually and over time.
Having said all that, if you're really interested in trying to "fix the tests", the PR is out and anyone can clone the repo and work on that PR - you can run the tests yourself, find out what's wrong and propose fixes. But what's actually happening here is different: users who have never been involved in the development of the provider are simply a bit impatient to get 10.0 out (after all we don't see lots of requests to help in other times); that in itself is of course fine and understandable.