Entity Key Inference

Question

Can any tell me if there is a way around the behaviour where EF will infer any non-nullable columns as entity keys in views? I can see from the VS 2010 beta that the same inference is still happening (though it still confuses me as to WHY), but I'm not able to determine whether there is a workable solution for removing the improper inference that won't get stomped by generated code every time you update the model.

These are the threads in which the problem has been discussed:

http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/ea0bf748-bc97-439d-99b0-76180b2161bb/

http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/86f231fb-c42f-4297-83f6-5ffd4e972e47

Thanks for any insight that can be provided.

Answer 1

Hi Kevin,

To my knowledge, there are no changes planned in this area in Visual Studio 2010.

There is a fundamental assumption in Entity Framework that entities have stable unique keys. When the design-time tools need to infer a unique key over table they can easily obtain information about the primary key. However, when they need to do it over a view, such metadata is not available, and so they fall back to this (somewhat optimistic) rule that says all non-nullable columns form a unique key. This makes views read-only for most effects and purposes.

As explained in the links you provided, you can manually change this information in the storage model and the conceptual model, but unfortunately, as soon as you update the schema from the database again, the information you entered manually is lost.

I will make sure the team working on the tools will get your feedback. Hopefully they will find a way to address this in a future release.

Thanks,
Diego

---

This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

Thanks Diego,

That's rather disappointing to hear.

In our particular scenario we are working on a major project (2y timeline) to re-write a legacy application, and the groundwork for this involves building many smaller projects to get us into and through a transition state. The only way we have found to effectively manage this mix of old and new data is to use SQL views with linked servers, so as not to duplicate key data in these transition projects. Updates have to be written to these views though, and the new projects also have regularly changing schema for the time being. Re-writing the model definitions with each update does not appear to be a workable solution for us, so for the time being we are instead using LINQ-to-SQL. There are many features of EF we wanted to take advantage of though, hence my repeated postings to find out if newer versions of EF are more reasonable towards views.

We'd also wanted to use EF for the major project (currently in the hands of the architect), but running into this issue with views has made us somewhat wary to date. Certainly we would not be as reliant on views with this project (since the idea is that it should stand on it's own), but I have to wonder what other gotchas we're going to run into when it comes time to write implementations. And the fact that these issues with key inference were reported over a year ago, but still persist in a major update to the product - well, that just seems somewhat ridiculous to me.

In the end, I don't think we're going to be waiting for any future releases. What would that be, VS 2012?? or will it be pushed to VS 2014? I've heard that particular line a few too many times I think.. There's open source alternatives that look much more promising (and less frustrating) at this point.

Answer 3

Hello Kevin,

 Given the amount of feedback about this issue, we decided to do an extra push and fix the problem. We are testing three changes to the designer:

1.       We sync the StoreGeneratedPattern from CSDL to SSDL.

2.       We sync key definition from CSDL to SSDL views. Not tables.

3.       Any SSDL view properties that are not mapped or are used in a condition we make non-keys. This supports TPH mapping to views as well as excluding arbitrary columns from the entity mapped to the view.

This should, we hope, take care of the issue you ran into, as well as some others.

Cheers,
 Noam

---

This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 4

That's excellent news Noam, and I look forward to testing it! Thanks.

...Kevin Dahl