-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for EF Core 8.0 #328
Comments
We're currently setting up and running our ODP.NET test suites with the new EF Core 8 bits. The official Oracle EF Core 8 release will be available by the end of the year. |
Ok, it would be great to be kept up to date on this since this is currently blocking our migration to .NET 8. |
Willing to look forward to the ef 8 update |
@mkstephenson You can subscribe to this GItHub thread. I will announce when Oracle EF Core 8 support becomes available here and close the issue. Alternatively, you can subscribe to the Oracle .NET twitter feed for the announcement: https://twitter.com/oracledotnet |
It has much better scaffolding capabilities for SQLite since dotnet/efcore#30816 TODO: Wait for Oracle, see oracle/dotnet-db-samples#328
It has much better scaffolding capabilities for SQLite since dotnet/efcore#30816 TODO: Wait for Oracle, see oracle/dotnet-db-samples#328
Confirmed NET 8 migration suspended due to lack of Oracle EF8 support... End of the year is too far away, to start well with our products in January! |
I agree. Oracle is ALWAYS the hold up for us unfortunately |
Agreed, when I told my team we wouldn't be able to upgrade to .NET 8 because of Oracle, the reaction was along the lines of "no surprises there". |
Folks, you know you can still migrate to .NET 8, right? You can't migrate to EF Core 8, but that's separate. You can target .NET 8 and still run EF Core 7 until Oracle releases their EF Core 8 packages. You're allowed to be frustrated, but be frustrated for the right reasons. |
True, improper wording, you're right. It is still frustrating that we can't upgrade to EF Core 8 at the same time we upgrade to .NET 8 because of Oracle |
I also upgraded my projects to .NET8 and kept all my Microsoft.EntityFrameworkCore.* packages to 7.0.3 version and is working fine with version 7.21.12 of Oracle.EntityFrameworkCore |
Good point, I totally forgot that was a possibility in the middle of all of my NuGet package conflicts... now I feel like a bit of a fool 😅 |
I'm sure we all agree that Oracle must place expedite their kind efforts in releasing Oracle EFCore 8. I wrote a stack overflow question about this, might be worthwhile up voting to help influence a speedy release: |
This is a long post. I want to give context about why provider support for EF Core 8 support takes time and .NET 8 support takes much less. The Oracle .NET team is aware of the EF Core 8 demand. We're working as expeditiously as possible. We expect Oracle EF Core 8 before the end of the year. It's hard to identify a specific date because you can't predict when all the significant bugs will be fixed such that the test criteria is met. When that happens, we ship Oracle EF Core 8. More about the context: In the old days of .NET FW, MS would make provider change decisions early on in their dev process and communicate that to partners. For example, the classic EF team would publish a spec on EF upon which provider writers could reliably design their providers from. Partners would even get the production bits early so that they could certify their various products on the the new runtime version before the official RTM date. When the official release came around, MS would not only have their own products well-tested by partners, they could also announce partner product certifications. In today's software world, software and APIs evolve fast. In fact, it's not uncommon for .NET APIs to change from production release to production release, breaking apps built on previous versions. If you follow the .NET previews and RCs, you see this happen more often. EF Core is no exception. For EF Core provider writers, the changes are often more significant. Downstream developers and customers don't necessarily see any API changes as a result of these provider changes. As ADO.NET is fairly mature in .NET 8 with limited to no breaking changes, it becomes straightforward for provider writer, such as Oracle, to certify. That's why ODP.NET could certify on .NET 8 in less than a week. Oracle got the final .NET 8 bits (at the same time you did). We set up our functional and stress test labs with those .NET 8 bits. We ran our tests and validated that there were no new significant issues. We then announced our certification. EF Core is more challenging to certify due to its provider model's changing nature. Even in release candidates, we have seen significant changes to the provider model that would break something working in the EF Core pre-release version right before that RC. When changes come that late, it's a challenge to implement a feature without a spec and limited doc for the provider writer. We can ask MS and look at the source code, which helps. But a curated doc/spec is fastest if the expectation from developers is to certify in the same month as the release. Once the provider writer knows what to implement, they need tests to validate the feature is working as expected. MS has been gracious in making its EF Core tests available. It does take time to port over tests of new features and incorporate them into Oracle's testing infrastructure. With all that said, this post is NOT blaming MS. In fact, they've been very communicative and helpful with the Oracle .NET team. We work with them closely. MS is being asked by its customers to innovate quickly. The fact that so many of you want to deploy EF Core 8 in production is testament to that. The goals of fast partner certification and fast feature innovation are to an extent mutually exclusive. I'm sure MS is doing its best to balance these two objectives as both are important to EF Core's success. I hope this post illuminates why partners need some time to certify on new EF Core releases. It's not just Oracle DB in this boat, MySQL, Pomelo, DevArt, and DB2 haven't released production EF Core 8 providers yet. Almost all the already supported EF Core 8 providers were delivered by MS dev team members. |
Oracle EF Core 8 now available: https://www.nuget.org/packages/Oracle.EntityFrameworkCore/8.21.121 |
Great. Marc |
@marcmognol That's correct. Oracle EF Core 8 only supports DB 19c and higher versions as documented in the Oracle EF Core 8 blog post announcement. |
Thank you. Marc |
There is any prevision to support Oracle 11.2 and 12? I have several clients that still use 11.2 and 12. |
@jlvsistemas It's possible that Oracle EF Core 8 could work against these two older DB versions. However, they haven't been tested. While it may be technically possible for Oracle EF Core 8 using ODP.NET 21c to work with these older releases, the last 21c version patch is planned for April 2024. At that point, there will no longer be new ODP.NET 21c patches (unless Oracle decides to extend the 21c support timeline). We will transition to using a 23c client version to deliver Oracle EF Core and ODP.NET fixes for EF Core 8. 23c only supports DB 19c and higher. That was the onus for our decision to only support DB 19c and higher. We would reach a point in the lifecycle such that backwards compatibility may break and couldn't be fixed as 23c clients were not designed to work with DB versions prior to 19c. To give you some context about how long these releases have been out of support, Oracle DB 11.2 Extended Support ended at the end of 2020. DB 12.2 support ended in 2022. |
Tested successfully, all my solution is now NET8, EF.Oracle OK... |
oracle efcore 8 facing scaffolding not working issue |
@jonyustc Do you want to share your scaffolding trace file to diagnose the problem? Some users have very large schemas, which can take a long time to scaffold. The scaffolding operation can appear to hang when run in those scenarios. However, it's not really hung, just taking some time to complete the operation. If you are only interested in scaffolding specific tables, specify just those tables only to scaffold. In my experience, I have found that will significantly speed things up. |
I have *.21.121 installed, along with Oracle.MangedDataAccess.Core 23.3.1-dev. Whats the timeline on Oracle,EntityFrameworkCore updating to resolve the warning warning NU1608: Detected package version outside of dependency constraint: Oracle.EntityFrameworkCore 8.21.121 requires Oracle.ManagedDataAccess.Core (>= 3.21.120 && < 3.22.0) but version Oracle.ManagedDataAccess.Core 23.3.1-dev was resolved |
@BartNSTCL Any reason you can't use ODP.NET Core 3.21.130? Is the question just about resolving the warning message or about a production supported release with 23c? Version 23.3.1-dev is a non-production version. Version 8.21.121 is a production release. |
I just have my Nugets set to Include Dev since there are some I use I need that. So once the -dev version is updated to release, I suspect the warning will go away. |
@BartNSTCL Yes, that is correct. |
If I read correctly, version 8 is valid and no longer compatible and usable for Oracle database version 11. Correct? |
@marcofacchetti That's correct. Oracle DB version 11 is out of support. The choices to remain supported are to stay with EFC 7 or earlier or upgrade the DB version. |
Since EF Core 8.0 was released yesterday, we were wondering when the Oracle.EntityFrameworkCore package will be adding support for EF Core 8.0?
The text was updated successfully, but these errors were encountered: