1

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 :).

Chris
  • 73
  • 1
  • 6

1 Answers1

3

You must query metadata and get list of all navigation properties

ObjectSet = context.CreateObjectSet<YourEntityType>();

// Get entity set for current entity type
var entitySet = ObjectSet.EntitySet;
// Get name of the entity's navigation properties
_propertyNames = ((EntityType)entitySet.ElementType).NavigationProperties.Select(p => p.Name).ToArray();

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.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Anything in particular from my very cursory description and made-up tables that makes you say that (the 'horrible' part)? – Chris May 12 '11 at 09:56
  • Yes, I come across Ladislav's answers here and there and they are usually of very high quality, but I am too, surprised about this "horrible architecture" part. @Ladislav: could you please expand a little bit on this, as it's not obvious what you mean? – Andrew Savinykh May 12 '11 at 10:39
  • 1
    @zespri, @Chris: If you use EF you define the model, you define the database and you write the code which uses your model, you test the application and you deploy it. Any change to the model is up to developers who must ensure that application still works and that none of use cases is broken by the change. Obviously the approach described in the question where Admin can trigger some automatic awesome feature which modifies model, regenerates classes, rebuild assemblies and redeploy application violates this pretty hard. I even don't understand why you do that, how can you use unknown feature? – Ladislav Mrnka May 12 '11 at 10:44
  • @Ladislav: I follow you. In truth, there is much more to it than I described, but I was trying not to make a huge post. The app is a CMS and the tables being created are predominantly using a table-by-type inheritance model off of a base content type. The system uses Dynamic Data for all of the CRUD operations, and the Admin tool (in our case the Admins are pretty much the development team) has protections in it to prevent alteration of core/required fields, etc. – Chris May 12 '11 at 15:22
  • @Chris: Ok, dynamic data - now it makes much more sense. – Ladislav Mrnka May 12 '11 at 15:24
  • The short is the app supports a multi-headed news org that requires the ability to create new content types with the same core capabilities (Security, Versioning, workflow, etc). If they want to track Appearances, an admin can create the new type based off of the core, add the fields needed to that type then flip the switch and have it wire it to all the various subsystems. After the prep, it takes about 45 seconds. More complex than that but you get the idea. Doesn't fully replace coding and testing for the app; just makes content type management faster and more consistent. – Chris May 12 '11 at 15:37
  • CMS usually model content types completely differently and they really don't have a new class for each content type. That makes them extensible. Your extensibility works but it is not automatic. – Ladislav Mrnka May 12 '11 at 15:48