实体框架核心添加如果不存在

发布于 2025-01-29 14:36:42 字数 851 浏览 5 评论 0原文

我使用此代码

using Microsoft.EntityFrameworkCore.ChangeTracking;

public static class DbSetExtensions
{
    public static EntityEntry<T> AddIfNotExists<T>(this DbSet<T> dbSet, T entity, Expression<Func<T, bool>> predicate = null) where T : class, new()
    {
        var exists = predicate != null ? dbSet.Any(predicate) : dbSet.Any();
        return !exists ? dbSet.Add(entity) : null;
    }
}

,并且

var purchase = new Models.Purchase();
var trackingnumber= "222";
_context.Purchases.AddIfNotExists(purchase, p => p.BankTrackingNum == trackingnumber);
await _context.SaveChangesAsync();

“在写入之前阅读”可以违反数据完整性而不会放入交易控制中。

在SQL Server中,我们可以使用Merge语句。但是,EF中没有合并语句。 您还知道交易以外的解决方案吗?

I use this code

using Microsoft.EntityFrameworkCore.ChangeTracking;

public static class DbSetExtensions
{
    public static EntityEntry<T> AddIfNotExists<T>(this DbSet<T> dbSet, T entity, Expression<Func<T, bool>> predicate = null) where T : class, new()
    {
        var exists = predicate != null ? dbSet.Any(predicate) : dbSet.Any();
        return !exists ? dbSet.Add(entity) : null;
    }
}

and

var purchase = new Models.Purchase();
var trackingnumber= "222";
_context.Purchases.AddIfNotExists(purchase, p => p.BankTrackingNum == trackingnumber);
await _context.SaveChangesAsync();

“Read before write” can violate data integrity without being put inside a transaction control.

In SQL Server, we can use merge statement. but merge statement is not available in EF.
Do you know the solution other than transactions?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

○愚か者の日 2025-02-05 14:36:42

这实际上是做到这一点的正确方法,钥匙的唯一性将从持久层中到达(并得到验证)。
您的“阅读之前阅读”根本不会引起任何问题,但是“在阅读和尝试写作时,另一个写作”会导致问题。

这是做到这一点的正确方法,您甚至可以将支票丢弃,因为DB总是会扔掉,并且只是故意处理“重复键”例外,只需确保有适当的约束即可。

对于主要问题,除非您分发锁定代码(假设您控制所有呼叫),则不能做太多。种族条件是真实的事情,但不太可能发生。

This is actually the proper way to do it, uniqueness of the key will come ( and be validated ) from the persistence layer.
Your "read before write" can cause no problem at all, but "an other's write while you read and try to write" would cause an issue.

This is the proper way to do it, you could even throw the check away since the db will always throw, and just handle the "duplicate key" exceptions on purpose, just make sure proper constraints are in place.

For the main problem you can not do much unless you distribute-lock the code ( assuming you control all calls ). Race conditions are a real thing but not likely to happen.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文