以下小編整理的entity framework常見錯誤的匯總,大家如果還有不明白可以在下面留言區討論。
1 實體屬性配置為isrequired()對更新的影響
拋出異常類型dbentityvalidationexception
表結構:
實體:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
public class user { public int id { get; set; } /// < summary > /// 賬號 /// </ summary > public string account { get; set; } /// < summary > /// 郵箱 /// </ summary > public string email { get; set; } /// < summary > /// 昵稱 /// </ summary > public string nickname { get; set; } /// < summary > /// 頭像 /// </ summary > public string avatarid { get; set; } /// < summary > /// 記錄插入時間 /// </ summary > public datetime inserttime { get; set; } /// < summary > /// 記錄修改時間 /// </ summary > public datetime updatetime { get; set; } } |
實體配置:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
modelbuilder.entity< user >().property(u => u.account) .isrequired() .isunicode(false) .hasmaxlength(50); modelbuilder.entity< user >().property(u => u.email) .isrequired() .isunicode(false) .hasmaxlength(100); modelbuilder.entity< user >().property(u => u.nickname) .isunicode(false) .hasmaxlength(50); modelbuilder.entity< user >().property(u => u.avatarid) .isoptional() .hasmaxlength(100); |
customdbcontext繼承自dbcontext
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
[dbconfigurationtype(typeof(mysqlefconfiguration))] public class customdbcontext : dbcontext { public customdbcontext() : base("name=master") { this.configuration.lazyloadingenabled = false; //dropcreatedatabaseifmodelchanges //new dropcreatedatabasealways< customdbcontext >() database.setinitializer< customdbcontext >(null); } public dbset< user > users { get; set; } protected override void onmodelcreating(dbmodelbuilder modelbuilder) { base.onmodelcreating(modelbuilder); entityconfiguration.set(modelbuilder); } } |
更新操作:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
using (customdbcontext db = new customdbcontext()) { user user = new user { id = 1, email = "[email protected]", }; dbentityentry< user > entry = db.entry< user >(user); entry.state = entitystate.unchanged; entry.property(t => t.email).ismodified = true; int num = db.savechanges(); } |
執行操作,報錯信息如下:
查看entityvalidationerrors,
只能看到{system.data.entity.validation.dbentityvalidationresult},沒有更詳細的信息。
如果將上述代碼用try..catch包起來,如下寫法:
1
2
3
4
5
6
7
8
9
10
11
|
try { //執行代碼 } catch (dbentityvalidationexception ex) { var e = ex.entityvalidationerrors; } catch (exception ex) { } |
一層一層地打開,看到真正導致異常的原因,看到下面的截圖:
分析實體配置發現,account屬性被設置為isrequired,那么在更新實體的時候,即使不更新這個字段,也要給這個字段賦值,那么賦值后觀察:
更新操作代碼變為
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
using (customdbcontext db = new customdbcontext()) { user user = new user { id = 1, email = "[email protected]", account = "a" }; dbentityentry< user > entry = db.entry< user >(user); entry.state = entitystate.unchanged; entry.property(t => t.email).ismodified = true; int num = db.savechanges(); } |
經過上述調整后,更新成功。
那么換一個思路,將account屬性被設置為isoptional()是不是也可以呢?
修改實體配置,將account屬性設置按如下修改,并注掉上面的account = "a"
modelbuilder.entity<user>().property(u => u.account)
.isoptional()
.isunicode(false)
.hasmaxlength(50);
執行測試,更改成功。
得出結論:在實體配置時,指定了為必選的字段,那么更新操作時,構造實例一定要對必選(isrequired())字段賦值。
上述測試中還有一個值得考慮的細節,構造user實例的時候,只對id,email進行了賦值,而沒有對其他屬性進行賦值,那么為什么會成功呢?那么必定是未進行任何設置的實體屬性默認是isoptional()。這跟表結構中的字段類型設置為not null有無關聯呢,從測試結果看就本類應用無必然聯系。
總結:
a.實體配置中指定了實體屬性為isrequired(),更新操作構造類的實例時必對此屬性賦值。
b.不進行配置的實體屬性默認為isoptional()
c.表結構中字段是否為not null對上述規則無影響。
2 更新報錯:
an object with the same key already exists in the objectstatemanager. the objectstatemanager cannot track multiple objects with the same key.
異常類型:system.data.entity.infrastructure.dbupdateconcurrencyexception
實體屬性配置如上例所示。
操作代碼:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
using (customdbcontext db = new customdbcontext()) { user user = new user { id = 1, email = "[email protected]", }; dbentityentry< user > entry = db.entry< user >(user); entry.state = entitystate.unchanged; entry.property(t => t.email).ismodified = true; user user1 = new user { id = 1, email = "[email protected]", }; dbentityentry< user > entry1 = db.entry< user >(user1); entry1.state = entitystate.unchanged; entry1.property(t => t.email).ismodified = true; int num = db.savechanges(); } |
執行操作
涉及到兩次修改操作,兩次操作構造了兩個實例,但是實例的屬性id有相同的值。
如果兩次操作的是同一個實例,而不是不同的實例,那么不會拋出異常,代碼如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
using (customdbcontext db = new customdbcontext()) { user user = new user { id = 1, email = "[email protected]", }; dbentityentry< user > entry = db.entry< user >(user); entry.state = entitystate.unchanged; entry.property(t => t.email).ismodified = true; dbentityentry< user > entry1 = db.entry< user >(user); entry1.state = entitystate.unchanged; entry1.property(t => t.email).ismodified = true; int num = db.savechanges(); } |
3 未給主鍵賦值或賦給主鍵一個不存在的值,拋出異常
system.data.entity.infrastructure.dbupdateconcurrencyexception
操作代碼如下,其中id=1這條語句被注掉,id是主鍵:
1
2
3
4
5
6
7
8
9
10
11
12
|
using (customdbcontext db = new customdbcontext()) { user user = new user { //id = 1, email = "[email protected]", }; dbentityentry< user > entry = db.entry< user >(user); entry.state = entitystate.unchanged; entry.property(t => t.email).ismodified = true; int num = db.savechanges(); } |
運行上述代碼,拋出異常信息如下,注意異常類型居然是system.data.entity.infrastructure.dbupdateconcurrencyexception,看上去像是并發問題,但實際卻不是!
message:
store update, insert, or delete statement affected an unexpected number of rows (0). entities may have been modified or deleted since entities were loaded. refresh objectstatemanager entries.
賦給主鍵一個不存在的值,令id=4(在數據庫表中不存在id為4的一條記錄)拋出的異常與上面的相同。
4 字段超長拋出異常:system.data.entity.validation.dbentityvalidationexception
表中nickname 字段定義為50個字符,現在賦值超過50。
操作代碼如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
using (customdbcontext db = new customdbcontext()) { user user = new user { id = 4, email = "[email protected]", nickname = "testupdateerrortestupdateerrortestupdateerrortestupdateerrortestupdateerrortestupdateerrortestupdateerrortestupdateerrortestupdateerrortestupdateerrortestupdateerror" }; dbentityentry< user > entry = db.entry< user >(user); entry.state = entitystate.unchanged; entry.property(t => t.email).ismodified = true; int num = db.savechanges(); } |
運行程序報錯:
一層一層點開,查看具體原因:
原文鏈接:https://www.cnblogs.com/hdwgxz/p/7897031.html