SQL Server and other databases support Unique Constraints on tables. Foreign key constraints are generally based on unique constrains on the principal side, with the Primary Key being only a special case of a unique constraint.
The Entity Framework currently only supports basing referential constraints on primary keys and does not have a notion of a unique constraint. The idea is to have:

• Support for specifying a unique constraint on an Entity
• Support for specifying a foreign key associations that on the principal end specify columns(s) that comprise a unique constraint but are not the primary key,

Currently the only conversion available in EF Core libraries 4.5 and EF 5.0 are enums mapped to integers but that is only tip of the iceberg. There is whole big feature behind - simple type mapping or conversions defined directly in mapping.

For example what if my database contains char column with Y, N values and I want to map it to bool property directly without any additional stuff doing the conversion inside my entity? Or more complex example - what if my column contains value like en-us and I want to map it to instance of CultureInfo? There are so many examples which can fit into this feature ...

Currently the only conversion available in EF Core libraries 4.5 and EF 5.0 are enums mapped to integers but that is only tip of the iceberg. There is whole big feature behind - simple type mapping or conversions defined directly in mapping.

For example what if my database contains char column with Y, N values and I want to map it to bool property directly without any additional stuff doing the conversion inside my entity? Or more complex example - what if my column contains value like en-us and I want to map it to instance of CultureInfo? There are…

I have seen simple select statements with 4 or 5 includes result in nearly 5000 line SQL statements when an equivalent hand-written SQL statement is ~15 lines. The performance of these queries along with the readability when debugging makes it an area that I would like to see the EF team focus on improving.

There is no ablity to filter included objects in ObjectQuery<TSource>.Include method.
Allow filter predicate in Include method in Entity Framework.
I suppose this method of ObjectQuery<TSource> may have following signature:

/// <summary>
/// Includes related objects which meet to predicate
/// </summary>
/// <typeparam name="TRelation">Type of related object on another end of navigation property</typeparam>
/// <param name="relationSelector">Expression that returns set of related objects</param>
/// <param name="predicate">Predicate that has to be met</param>
/// <returns>Query</returns>
public System.Data.Objects.ObjectQuery<TSource> Include<TRelation>(Expression<Func<TSource, IEnumerable<TRelation>>> relationSelector, Expression<Func<TRelation, bool>> predicate);

It's unfortunate not to be able to mark interfaces for EF mapping (code first). This will allow to really abstract the implementation. Allows a unique representation of the data in the context of RIA Services (if Ria Services allows also for interface 'mapping'). This won't be very hard to implement since EF is happy when it subclasses... For the benefits: imagine you have only interfaces to declare your model. On the server side, you use EF to get your interfaces 'filled' from DB. on the client side you get those same interfaces filled by RIA services... You can reuse any algorithm against your data.
I am not sure this idea will be implemented one day. If it is then I have many other ideas to enhance its usage...

It's unfortunate not to be able to mark interfaces for EF mapping (code first). This will allow to really abstract the implementation. Allows a unique representation of the data in the context of RIA Services (if Ria Services allows also for interface 'mapping'). This won't be very hard to implement since EF is happy when it subclasses... For the benefits: imagine you have only interfaces to declare your model. On the server side, you use EF to get your interfaces 'filled' from DB. on the client side you get those same interfaces filled by RIA services... You can reuse any…

Problem Description:
For TPT inheritance, the more subclasses you add, the time it takes to generate SQL, and the complexity of the SQL query itself, become unmanageable. With a simple base class (5 or 6 fields), and around 30 simple subclasses (2 or 3 fields a piece), it takes almost 2 minutes to generate the SQL (ObjectQuery.ToTraceString()) and execute it on the server. EF generates almost 8000 lines of SQL for a simple select query on the base class. This is because the SQL generated is a mess of crazy subselects, joins, and unions. Even with empty tables (so that a query would return no data), it takes that long to generate and execute the SQL.

Doing a simple "flat" query (no subselects), left joining each subclass table, could produce the same results, but with infinitely better performance. You wouldn't need any unions either. As it stands, even with just 3 or 4 subclasses, EF TPT inheritance can not be used in any kind of production environment.

I have written an article that describes this problem in more detail, where I have modeled and graphed the performance degradation as the number of subclasses go up.

Note that I have selected EF4 as the version, but this is equally applicable to EF 3.5 SP1. I have tested in both and the behavior is exactly the same.

Problem Description:
For TPT inheritance, the more subclasses you add, the time it takes to generate SQL, and the complexity of the SQL query itself, become unmanageable. With a simple base class (5 or 6 fields), and around 30 simple subclasses (2 or 3 fields a piece), it takes almost 2 minutes to generate the SQL (ObjectQuery.ToTraceString()) and execute it on the server. EF generates almost 8000 lines of SQL for a simple select query on the base class. This is because the SQL generated is a mess of crazy subselects, joins, and unions. Even with empty tables (so that…

In entity framework there should be a way to eager load (include) navigation properties of a derived class.

When in an data model for entity framework has a navigation property it is not posseble to eager load that navigation property besides when using OfType<> or when eager loading the derived type itself by a navigation property.
This could be done by using a special syntax of the include path.
Since a property of the base class can not have the same name as the derived class, it would also be possible to navigate to the derived class by its name.

e.g.: If class Derived inherits from Base and has a navigation property named Prop one could say
dbContext.BaseSet.Include("Derived.Prop")

this should query all entities of type Base and eager load property Prop for all instances of Derived in the reslult list

In entity framework there should be a way to eager load (include) navigation properties of a derived class.

When in an data model for entity framework has a navigation property it is not posseble to eager load that navigation property besides when using OfType<> or when eager loading the derived type itself by a navigation property.
This could be done by using a special syntax of the include path.
Since a property of the base class can not have the same name as the derived class, it would also be possible to navigate to the derived class by its name.

Entity Framework should support automatic deletion of orphan records, the way "all-delete-orphan" works in NHibernate.

If I have a one-to-many relationship between Orders and OrderLines, and code inside the Order class calls OrderLines.Remove(orderLine), this should cause the order line to be deleted when I save changes. Currently, EF attempts to set the order line's OrderID to NULL. If the OrderID column is non-nullable, the update fails with a constraint violation error.

This is an important feature for an ORM, since it's difficult to cleanly work around it. One workaround is to add a call to context.OrderLines.Delete(orderLine) immediately when an order line is removed in memory. But the Order aggregate should be able to manage its order lines without taking a direct dependency on the ORM.

Entity Framework should support automatic deletion of orphan records, the way "all-delete-orphan" works in NHibernate.

If I have a one-to-many relationship between Orders and OrderLines, and code inside the Order class calls OrderLines.Remove(orderLine), this should cause the order line to be deleted when I save changes. Currently, EF attempts to set the order line's OrderID to NULL. If the OrderID column is non-nullable, the update fails with a constraint violation error.

The EF team has marked the previous TVF feature suggestion as Completed saying TVF support will be included with .NET 4.5. It had 226 votes at the time. However, this excludes Code First support. Vote for this suggestion to specifically add Code First support for TVFs.

Instead of having EF connect to SqlServer or Oracle or whatever ... have the ability to provide an InMemory provider ... so our unit tests or general development can be quick. There's no .dbf or whatever. No triggers or stored procs or views. Just list or hashset backing collections (behind the scenes). Simple, yet fast.

Example scenario's.

The common : Blog posts and Users. When a person creates a new blog post (which is represented as an entity on the edmx) and adds a User to that blog post, (ie. the user who is making the post), the inmemory context adds the instance to the BlogPost repository and to the user repository (if the user doesn't exist). All very simple crud BUT the EF is smart enough to 'remember' these enties, their data AND most importantly, their relationships.

Currently, if we create a generic IRepository<T> and some fake InMemory unit of works and/or InMemoryContexts .. they do know how to update other repositories -- relationship management doesn't exist.

So .. it would be so helpful if EF can handle an inmemory situation. We would have the manually populate the data for each repository/entity .. which is perfect .. so it keeps things simple .. but fast.

Instead of having EF connect to SqlServer or Oracle or whatever ... have the ability to provide an InMemory provider ... so our unit tests or general development can be quick. There's no .dbf or whatever. No triggers or stored procs or views. Just list or hashset backing collections (behind the scenes). Simple, yet fast.

Example scenario's.

The common : Blog posts and Users. When a person creates a new blog post (which is represented as an entity on the edmx) and adds a User to that blog post, (ie. the user who is making the post), the inmemory context…

At time we may require to lazy load at column level. For e.g. if we have a LOB column which could be huge, we may not want to load that upfront when the table is lazy loaded. Agreed that we can workaroudn this problem, but a straight forward way would be good to have

The only way to set a default date in the entity data model is to put a hard date in there, a string. If you have a known default date (e.g. 1900-01-01) this is fine. But often we want NOW to be the default and there's now way to indicate that in the model. Additionally, if there was a way to indicate EF should use the providers minimum value that would be nice. Even if it meant typing "SqlServer.MinDate' into the default attribute in the property window.

Even if the database knows how to set the default value, we can't benefit from that and leave the date empty when updating (value type ...no such thing as empty). We can't make it computed or it essentially makes the field read only.

I personally use validation code or constructors to set a default date, but I think that many people would benefit by being able to ahve a way to set "now" as a default directly in the model.

get asked about non-nullable date defaults frequently.

The only way to set a default date in the entity data model is to put a hard date in there, a string. If you have a known default date (e.g. 1900-01-01) this is fine. But often we want NOW to be the default and there's now way to indicate that in the model. Additionally, if there was a way to indicate EF should use the providers minimum value that would be nice. Even if it meant typing "SqlServer.MinDate' into the default attribute in the property window.

A problem encountered when an entity is instantiated using non-ef infrastructure, e.g. ASP.NET MVC model binder mechanism. Such entity is pure poco class without proxy. Updates of relationship of the entity can be only synchronized using manual approach according to MSDN(and proven by experience)
http://msdn.microsoft.com/en-us/library/ee373856.aspx "If you are working with disconnected objects you must manually manage the synchronization."
Manual synchronization is really painful approach and really not a good ORM style solution.
The problem even becomes critical for me in decision to migrate my application to nhibernate due to the fact that nhibernate can do such synchronization without problems http://www.codinginstinct.com/2009/11/nhibernate-feature-saveorupdatecopy.html…

The current implementation of self-tracking entities is error-prone especially when combined with disconnected scenarios, such as, when using WCF services. The reconciliation process with the ObjectStateManager is convoluted and makes it easy to trip up when saving larger aggregates with Self-Tracking Entities. I would like to see more effort put in to improve the Self-Tracking Entities template and to improve how EF and Self-Tracking Entities interact.