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

Feature like enum mapping scales EF mapping features by inches. Ability to define custom conversion or simple type mapping scales EF mapping features by miles.

Entity designer is practically useless with non trivial models (for enterprise applications). Generate model from DB with more than 200 tables with FKs (I have tried on 350+ 9Mb edmx), and try to move entities and so on. It is nightmare.
Possible improvements:
1) Profile and optimize :)
2) To have option: To show or Not relationships.
3) To have option: Display or not fields in table.
4) To have subject areas: Render only subset of tables.
5) Separate model to several edmx’s and have ability setup relations between entities from different edmx’s.
6) To explore tools like ErWin, Power Designer and so on and fined other ideas.

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>http://samscode.com/index.php/2010/01/the-entity-framework-v1-and-v4-deal-breaker-tpt-inheritance/

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:
The following LINQ-to-Entites query will return the expected results:
var result = from o in table
where o.column == null
select entry;

However, the following query will never return any results:
int? myNullInt = null;
var result = from o in table
where o.column == myNullInt
select entry;

This is because the first query is correctly generating a 'column IS INT' query, while the second one generates a 'column = @p_linq_p; @p_linq_p = NULL'.

This problem affects both LINQ-to-Entities and LINQ-to-SQL. However, while LINQ-to-SQL has the not-so-bad workaround
where o.column.Equals(myNullInt)
The workaround for LINQ-to-Entities is much harder to follow and more painful to write:
where (myNullInt == null ? o.column == null : o.column == myNullInt)

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.

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.

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.