Use this issue to make comments, ask questions, etc. about weekly updates posted in #15403 and #19549
I have some questions regarding the new query pipeline.
@davidroth
EF Core now targets .NET Standard 2.1
Does that mean EF Core won't be usable for UWP? (I may be the few who uses EF Core on UWP :-P)
@KexyBiscuit That depends on whether UWP will support .NET Standard 2.1, which is unfortunately a question that I am not able to answer.
@KexyBiscuit It looks like you already asked a similar question. If UWP and .NET Core 3 converge as Charles claims, and .NET Core 3 implements .NET Standard 2.1, then...
@bricelam Yes, I did ask "will it", and now I'd like to know "when", though I know these schedules are likely confidential. In fact, I didn't expect that EF Core will target .NET Standard 2.1 this early. 馃槩 Maybe I have to go back to 2.2...
I would like to ask if #18831 could go into 3.1. It's a critical issue for us. There is no workaround, and the fix seems trivial to add to 3.1, and maybe even 3.0 as well.
@mbp In addition to the workaround posted on the issue we will discuss whether to patch this in a 3.1.x release.
What is your policy of releasing bugfixes merged to master in a 3.1.x release? Specifically #19514, because I would really like to avoid using a nightly build in production.
@lara-ec We make a decision on whether to patch for a given issue based primarily on:
Hi, could you consider adding issue #7829 to the 5.0 release. Thanks.
very excited to see many-many was underway 馃コ
@JonPSmith Happy to consider it--what's the specific value that this issue brings that means it should bump other things in 5.0?
Hi @ajcvickers,
I am not saying it is a high priority, but if it can be done it can help with database validation. Obviously it depends on how difficult it is, which I cannot judge.
My reason for asking for this features is because I consider catching non-unique values something I should do in the database (doing outside has some difficulties). I have code that captures a DbUpdateException exception and if it is a unique database exception I pass it to the code below to return a user-friendly error message from a SQL Server 2601 or 2627 error.
```c#
private static readonly Regex UniqueConstraintRegex =
new Regex("'UniqueError_([a-zA-Z0-9])_([a-zA-Z0-9])'", RegexOptions.Compiled);
public static ValidationResult UniqueErrorFormatter(SqlException ex,
IReadOnlyList
{
var message = ex.Errors[0].Message;
var matches = UniqueConstraintRegex.Matches(message);
if (matches.Count == 0)
return null;
var entityDisplayName = entitiesNotSaved.Count == 1
? entitiesNotSaved.Single().Entity.GetType().GetNameForClass()
: matches[0].Groups[1].Value;
var returnError = "Cannot have a duplicate " +
matches[0].Groups[2].Value + " in " +
entityDisplayName + ".";
var openingBadValue = message.IndexOf("(");
if (openingBadValue > 0)
{
var dupPart = message.Substring(openingBadValue + 1,
message.Length - openingBadValue - 3);
returnError += $" Duplicate value was '{dupPart}'.";
}
return new ValidationResult(returnError, new[] {matches[0].Groups[2].Value});
}
```
This works but it is a) different for each database type, and b) is fragile as the message may change. If it was possible to get the entity that caused this then it makes building the user-friendly error message easier.
Hi,
I wondered if you were look at Cosmos DB. There is one feature, #16146 (Support aggregate operators), which I think developers would find odd not to have. Is this worth considering in EF Core 5?
@JonPSmith you are aware that the 3.1 Cosmos provider has 9000 downloads, compared to 1 million downloads of the 3.1 SQL Server provider?
Wow, I didn't know that. I take back my Cosmos DB suggestion as its not worth the effort for that many users.
Personally I like the Cosmos DB support, but I haven't used it in a client system yet, but if I need great read scalability then I would consider it (see my article on this).
It would be interesting to see how many people are using Cosmos DB generally. I was talking to a team at NDC London that had implemented a CQRS architecture with EF Core SQL Server for the write side and and Cosmos DB for the read side. They built this before EF Core 3 and accessed Cosmos DB directly. There only comment was that Cosmos was still quite pricey, even with the new Autopilot system.
@JonPSmith @ErikEJ With the Cosmos provider we're in a bit of a holding pattern right now. We got to a point with 3.1 where we think there is enough for people to try it. We're now very interested hear from people what issues they run into and what additional functionality they need. (Your feedback has been great, @JonPSmith!)
It's not a surprise that the usage numbers are low right now compared to SQL Server. The important thing is how they trend and how they track relative to total Cosmos usage. (Counting these things is hard, btw. NuGet package downloads are very crude and often misleading.) Also, highly engaged customers who are blazing the way are more important for getting feedback than the total number of people, some of which will be just kicking the wheels.
A very positive sign is that we've been getting community PRs fixing and adding things to Cosmos--for example, '_etag' support last week.
So there isn't much specific to Cosmos in the 5.0 plan, but that doesn't mean it will stay like that post 5.0.
@ajcvickers any idea when EF Core 3.1.4 will be shipped? Looking forward to this issue #19616 to be fixed as it holds many of us upgrading to .NET Core 3.x
@asyncoder 3.1.4 is tentatively scheduled for May. I know that's a long time out, but there are other inputs to this release across .NET that require it to be pushed out. The 5.0 daily builds already contain these fixes, which might be an options for you. We build and test the daily builds with .NET Core 3.1.
Hi team! Great progress in EF Core 5.0! Congrats!
FYI these three bullet points are duplicated at the en of the EF Core 5.0 list of improvements:
Thanks @divega! Looks like @smitpatel fixed it. :-)
Split include is still in-progress? I thought you guys finished it. 馃憖
@smitpatel Fixed.
Most helpful comment
very excited to see many-many was underway 馃コ