Plan for Entity Framework Core 7.0 #26994
Comments
|
How about #1387 (including/excluding specific properties when loading an entity from the database)? Together with bulk updates/deletes that's the main thing that's missing from EF Core for me. |
|
Looks great! Have you also considered looking at #13617 (parameterizing |
|
This is very exciting, especially if the JSON column support allows for polymorphic strongly typed JSON,(via a discriminator field) to come back. Think unions. Also consider ways of supporting all the fantastic operators postgres has for JSON that can take advantage of indexes! I'd like to offer a screen share if it would help the EF team to see what I'm doing currently. |
|
@sveinungf there are numerous ways to fix that |
|
Great plan! I was hoping to see #9630 included though 😥 |
|
Please, please, pretty please fix the async issues with varchar(max) columns, see for more info: If performance is important for EF Core then this one should really be fixed ;-) And preferably fix it in EF core 6. |
|
@HaroldH76 the problem isn't in EF Core, it's in SQLClient, there's nothing really we can do to fix that... |
|
But both are Microsoft? So maybe EF Core team can push SqlClient team? |
|
@HaroldH76 I'm not too sure what primary key caching you're referring to... the way to avoid this issue is to use sync APIs instead of async when dealing with large columns. We're in touch with the SqlClient people, but ultimately this has to be fixed there. |
|
@sveinungf Parametrization for IN queries is top of the list of bigger features that didn't make the cut. |
|
@davidroth Two questions:
|
|
Bulk operations would be great, but why only update? what about Bulk insert ? For my apps Bulk insert is even more important. |
|
@Martinn2 EF Core already does a form of bulk insert - if you add multiple instances and then call SaveChanges, all insertions will happen in a single roundtrip, which is quite efficient. More importantly, bulk update and delete are very similar in that the user provides a LINQ predicate defining which entities are to be updated/deleted, and that gets executed in the database (e.g. via SQL UPDATE or DELETE). Bulk insert is a completely different feature which doesn't have anything to do with that. |
|
@roji On Entity framework extensions, they have an online compare of their BulkInsert and SaveChanges in .NET Fiddle: https://dotnetfiddle.net/ttbri7 When I run this with 4000 entries, I got the following results:
As you can see, SaveChanges is more than 6x slower. I understand that is is different from updating and deleting, but IMHO bulk insert is even more important |
|
@Martinn2 see #15059, and please let's keep any further conversation about bulk insert in that issue rather than here. tl;dr we do agree that EF Core's bulk insert could be optimized (see for example #9118 which is planned for 7.0), but our main focus here is database-only bulk update and delete, which are currently unsupported in EF Core and can make a huge difference. |
|
Do you plan MySQL low level support without any additional nuget package? |
|
@Meister1977 what are you referring to exactly? There are already two EF Core providers for MySQL, see the providers page. All providers come as separate nuget packages, including the SQL Server and SQLite ones, which are maintained and delivered by the EF team. |
I am mostly interested in the ownership of polymporphic collections. Regarding table mapping: In the OrderPosition example I would like to see TPH or TPT/C for the Position types:
|
|
Just a few quick questions: Is there any priority amount the different things planned? Are there some which are more "safe" for the 7 release and some which are less safe? What's the reasoning behind not having a 6.1 release? Thanks for your work! |
That's a good question. I'll discuss with the team whether there is some way we can provide any additional information here. /cc @JeremyLikness
We align with .NET releases, which have converged to a regular schedule of one release per year. There are a lot of good reasons around this in general, but this isn't the best place to discuss them and I'm not the right person to express those reasons. The reason for explicitly stating this in the EF Core plan is to avoid people having any expectations to the contrary. |
|
A bit 😞 that nothing from #21459 has made it to EF7. Need more votes... |
|
As well a bit 😞 that #4823 did not make it to EF7. |
|
Will we get any support for Event Sourcing like Marten (https://martendb.io/) |
|
How about the Distributed transaction for non windows platform? |
|
@rcbellamy here's my personal take here, as a member of the EF team. First, the parts in your comments which I find inappropriate in the professional setting, contrary to our code of conduct and offensive are:
Moving beyond these to your specific arguments. I've reread what you wrote, and to my understanding your complaint is about the low quailty of our documentation, and about the fact that we continue improving the product (with enhancements), while the documentation gap remains unaddressed ("Honestly, for the remainder of the EF7 timeframe and the entirety of the EF8 timeframe, Microsoft's only focus should be improving the documentation for the currently existing features."). I don't view these arguments as insulting or a violation of our CoC (as opposed to the two comments I cited above), but do think they are without merit and do not correspond to the reality of the vast majority of our users. First, we invest a lot of effort into the EF Core documentation, and generally receive very good feedback about them from users; I don't think it's accurate that "much of the documentation is actually far behind fully-released updates to EF Core". In general, documentation is never perfect and never reaches 100% coverage, just like a product is never 100% bug-free. Just like with features and bugs, we prioritize writing documentation based on how many users are affected (and how severely), basing our estimation on user feedback (among other things). Important features are documented promptly (at the end of the release), while exotic edge cases may take a long time to get prioritized. I do not believe it's in our users' best interests to halt all feature work and write docs for scenarios which affect only a handful of users, and all the feedback we're getting from our users confirms this. It's also important to understand that documentation isn't everything. In some cases, users aren't able to accomplish what they want exclusively by reading official documentation or a book, and get their answers on Stackoverflow, external blog posts, or by posting an issue on our github repo. I don't believe this should be viewed as a necessary failure, or something that needs to be fixed: in modern software development docs are one resource alongside several others. Of course, when we see that many users are reaching to us with the same problem, we take that as a signal that the docs should be improved, and do that. Finally, rather than this general, abstract discussion, I'd recommend opening specific issues on concrete documentation gaps you find, on our documentation repo. The only actual, concrete complaint I can see from you is in #28047 about the use of DataDictionary. In that issue, we pointed to docs touching on the general area, and though I agree those docs could be improved, yours is the only case AFAIK where a user tried to use DataDictionary in this way; as such, like I explained above, prioritizing those docs wouldn't be the interest of our users. I do encourage you to open other issues on difficulties you encounter while using EF Core, and documentation gaps you identify. We'll be here to help you out, and where it makes sense, we'll also update our docs to help other users not encounter the same difficulties. |
|
You are correct that I am not providing very specific, detailed criticism of specific documentation failures. However, I read about 400 pages of EF Core documentation, and if I were to submit specific criticisms, they would themselves fill an entire book. You say that "[you] don't believe [that documentation that isn't fully complete] should [necessarily] be viewed as a []failure[.]" I do not disagree with that. However, when the development is so far ahead of the documentation that the gap between the documentation and the current API makes it so much more difficult to use the product that this difficulty has a larger, negative effect on the value of the product than the value of the new features, that is destroying your own product in the name of "expanding functionality." You must realize that there are a lot of mistakes that would be readable by someone that already understands the material covered better than they understand the English language. Microsoft needs to focus on finding people that actually do speak English fluently to explain their products to people that do not already know the products well enough to not need the documentation in the first place. Technical experts that still fail to understand which ending is the right ending for the root word that they are using are not qualified to assess the quality of English-language documentation. |
|
I would have to disagree on the fact that there would be no need for documentations, there are people like me who understand things better with samples or seeing it done from somebody first. It all depends on how people learn how to use frameworks properly and people always learn in different ways and that is why documentations exist. Without documentations it can communicate an toxic environment in terms of how the framework is in difficulty which would in a way kill projects which don't write documentations. This is why it is very important to get right when the code ships stable releases. |
|
@ajcvickers I would like to check if an initial implementation is planned for Azure Synapse per plan? |
|
@ilazarevski Have you tried it with Azure Synapse - and what is not working? |
|
I didn’t test it, but first I wanted to check if it is already included in the preview. I will check and inform you about the results. |
|
@ilazarevski in principle, at least basic EF scenarios should work with Azure Synapse as the latter supports T-SQL. If you run into any specific problems, please open separate issues for these and we'll investigate. |
|
@ilazarevski I also did an effort a while ago to make database first scaffolding work with "Azure SQL Data Warehouse" |
|
@ErikEJ Nice to hear and thanks for the information. I will check and if it necessary I will post back. |
|
I'm getting worried Value Objects won't make it for 7.0 despite being part of the plan. I'm sure you're well aware and haven't forgotten about it, but just a friendly reminder that it's a feature I'm (and lots of others) very much looking forward to! 😊 |
|
@cjblomqvist Unfortunately, value objects is not going to make it. This was a painful cut to make. We know people are waiting on this, and it will be a high priority for EF8. |
|
Oh no, if only someone could have helped with implementing value objects so then it could have made it in. |
|
@AraHaan I doubt that would be realistic. It's a difficult, complex feature. |
|
I am very sad, that bulk inserts are not there. Any specific reason, except maybe constraints? |
|
@DerGuru inserts are batched in SaveChanges already. Or are you thinking of something else? |
|
@DerGuru @ErikEJ there's #27333 for a bulk import API over e.g. SqlBulkCopy; this hasn't been done because there have been other more important and highly-voted features. But as @ErikEJ wrote, our regular SaveChanges batches and the performance isn't too bad, unless you're really importing huge amounts of data. |
|
A real bulk import (via e.g. SqlBulkCopy) will likely perform noticeably better for this, though if it's a relatively one-time thing, the difference shouldn't be important and EF should be good enough. I suggest just setting up a quick benchmark yourself, it's really easy (use BenchmarkDotNet). |
Batches are not the same, as one single SQL statement. For large quantities the difference is significant. I am talking about 50000-100000 rows, which we chunk into 1000, currently, as part of some automated task. |
|
@DerGuru when inserting multiple rows into the same table, EF Core does combine multiple insertions into a single INSERT or MERGE command. This is still not as efficient as using SqlBulkCopy, which is a high-speed data import mechanism, but it should be already quite optimized. In any case, I don't think it makes sense to continue this conversation on this issue. We already have #27333 covering an abstraction over SqlBulkCopy, and apart from that the regular SaveChanges is already quite optimized (e.g. via MERGE). |
|
You are right…
… Am 21.08.2022 um 22:21 schrieb Shay Rojansky ***@***.***>:
@DerGuru when inserting multiple rows into the same table, EF Core does combine multiple insertions into a single INSERT or MERGE command. This is still not as efficient as using SqlBulkCopy, which is a high-speed data import mechanism, but it should be already quite optimized.
In any case, I don't think it makes sense to continue this conversation on this issue. We already have #27333 covering an abstraction over SqlBulkCopy, and apart from that the regular SaveChanges is already quite optimized (e.g. via MERGE).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
Will EF7 be only NET7.0 once GA or will it support NET6.0 as well? |
|
@pinkfloydx33 .NET 6 |
|
Really? Great news! Thanks |
ajcvickers
added
the
closed-no-further-action
and others
Today we are excited to share with you the plan for Entity Framework Core 7.0. This issue contains a quick summary of the plan and acts as a place for you to leave feedback.
This plan brings together input from many stakeholders and outlines where and how we intend to invest in Entity Framework Core 7.0 (EF Core 7.0.) For brevity, EF Core 7.0 is also referred to as just EF7.
General information
EF Core 7.0 is the next release after EF Core 6.0 and is currently scheduled for release in November 2022 at the same time as .NET 7. There are no plans for an EF Core 6.1 release.
EF7 will align with the .NET support policy and will therefore not be a long-term support (LTS) release.
EF7 currently targets .NET 6. This may be updated to .NET 7 as we near the release. EF7 does not target any .NET Standard version; for more information see the future of .NET Standard. EF7 will not run on .NET Framework.
Themes
The large investments in EF7 will fall mainly under the following themes.
Highly requested features
As always, a major input into the planning process comes from votes (👍) for features on GitHub.
dotnet ef database scaffoldcan be fully customized..NET platforms and ecosystem
Much of the work planned for EF7 involves improving the data access experience for .NET across different platforms and domains. This involves work in EF Core where needed, but also work in other areas to ensure a great experience across .NET technologies.
dotnet efcommands are easy to use and work with modern platforms and technologies.Clear path forward from EF6
EF Core has always supported many scenarios not covered by the legacy EF6 stack, as well as being generally much higher performing. However, EF6 has likewise supported scenarios not covered by EF Core. EF7 will add support for many of these scenarios, allowing more applications to port from legacy EF6 to EF7. At the same time, we are planning a comprehensive porting guide for applications moving from legacy EF6 to EF Core.
Performance
Great performance is a fundamental tenet of EF Core, lower-level data access, and indeed all of .NET. Every release includes significant work on improving performance.
Find out more and give feedback
This post is a brief summary of the full EF7 plan. Please see the full plan for more information.
Your feedback on planning is important. The best way to indicate the importance of an issue is to vote (👍) for that issue on GitHub. This data will then feed into the planning process for the next release.
In addition, please comment on this issue if you believe we are missing something that is critical for EF7, or are focusing on the wrong areas.
The text was updated successfully, but these errors were encountered: