实体框架 - 反向外键检查
我们有一个系统,允许管理员在系统内构建新的内容类型,包括与其他表的外键链接。然后,管理员可以重建数据库,此时它会创建表和所有必要的关系,然后重建 EDMX 并重新编译所有内容。像冠军一样工作(我没有写它,或者我可能知道这个问题的答案)。
我们遇到的一个缺点是,当用户去删除可能与另一个表中的项目链接的记录时。由于引用完整性,这会引发错误。当然,我正在捕获这个,但我现在所能提供的只是一个通用的“您无法删除此项目,因为它链接到某些东西”类型的错误。我宁愿检查该项目是否可删除,如果不可删除,则禁用该按钮。
有没有一种方法可以在运行时确定要删除的项目链接到哪个表/行?通常,我只会查询相关表,但由于此应用程序的性质,我不知道其他表在设计时是什么。
简而言之,如果我有:
Foo: FooID, FooName 酒吧:BarID、FooID、酒吧名称 Pow: PowID, FooID, PowName
是否可以在运行时判断 Foo 中的一行由于来自 Bar 或 Pow 的 FK 链接而无法删除,如果是这样,我可以判断哪个表导致了错误吗?
提前致谢;第一次在这里发帖,所以请原谅任何礼仪错误:)。
We have a system that allows Administrators to build out new content types within the system, including foreign key linkages to other tables. The Admin can then rebuild the database, at which point it creates the tables and all the necessary relationships, then rebuilds the EDMX and recompiles everything. Works like a champ (I didn't write it or I might know the answer to this).
One drawback that we have is when a user goes to delete a record that may be linked to by an item in another table. This throws an error due to referential integrity. I'm trapping this, of course, but all I can provide right now is a generic 'You can't delete this item because it is linked to something' type of error. I would much rather check to see if the item is deletable and disable the button if not.
Is there a way that I can determine to what table/row the to-be-deleted item is linked, at runtime? Normally, I'd just query the related tables but due to the nature of this app, I don't know what those other tables would be at design-time.
So in short, if I have:
Foo: FooID, FooName
Bar: BarID, FooID, BarName
Pow: PowID, FooID, PowName
Is it possible to tell at runtime that a row in Foo cannot be deleted due to a FK linkage from either Bar or Pow and, if so, can I then tell which table is causing the error?
Thanks in advance; first posting here so please excuse any etiquette flubs :).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您必须查询元数据并获取所有导航属性的列表
现在您拥有在删除之前必须检查的属性。要检查属性,您必须加载这些成员,并且必须检查相关实体是否存在。两者都可能需要大量的反射,这会影响应用程序的性能。
我不得不说你的应用程序架构太糟糕了。就像一个例子:什么地方不应该使用EF或者如何不应该使用EF。
You must query metadata and get list of all navigation properties
Now you have properties which must be checked before deletion. To check properties you must load those members and you must check if related entity exists. Both will probably require a lot of reflection which will affect performance of your application.
I have to say that your application architecture is horrible. It is like an example: where should EF not be used or how should EF not be used.