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.

Some times, depending on how you design your model, you want a certain navigation property to be loaded *always*. It's static part of the model just like the (implicit) lazy load nature of a virtual navigation property when lazy loading is configured.

There should be a way to define eager load for navigation properties, something like:

[Include]
public ICollection<Item> Items { get; set; }

and/or via DbModelBuilder:

modelBuilder.Entity<Order>().Property(x => x.Items).Include();

This would greatly simplify client code as it wouldn't have to include on each query/access, and it would also work with Find(key). This would make it more suitable to DDD-style design of entities (so called aggregate roots).

I supposed that eager loading currently supports only single fixed strategy and except some rare cases this strategy always joins all eager loaded data to one huge record set - at least that is what I saw so far.

I described the impact of such eager loading on Stack Overflow: http://stackoverflow.com/q/5521749/413501

It would be nice to have some control over the way how eager loading is executed with possibility to define if eager loaded data should be joined into single result set with the main data or if they should be executed in separate query.

Something like:

var data = context.Items
.Include(p => p.ParentItem, EagerLoadingStrategy.JoinQuery)
.Include(p => p.SubItems, EagerLoadingStrategy.SeparateQuery);
.Where(p => p.Id == 123);

Generated SQL executed in single roundtrip (the main difference between using separate LINQ queries) will look like:

/* Base item query with joined parent */
SELECT i.Id AS ...,
i.ParentId AS ...,
i.Name AS ...,
p.ParentId AS ...,
p.Name AS ...,
FROM Items AS i
LEFT JOIN Items AS p ON i.ParentId = p.Id
WHERE i.Id = 123

/* Separate query for children */
SELECT c.Id AS ...,
c.ParentId AS ...,
c.Name AS ...
FROM Items
WHERE c.ParentId = 123

It would be also nice to be able to set default strategy globally per context instance.

At the moment I'm not sure if there is another useful strategy for the eager loading but perhaps a community will find another.

** SUGGESTION **
Native support for query serialization and deserialization (to XML) decoupled from a concrete ObjectContext, including query parametrization and correct management of lambda expressions (e.g. using expression expansion as in LinqKit).

** WHY **
We've developed a set of classes that allow a query to be written in the client layer and executed in the service layer via web services (with POCO entities). After the query is written normally using linq to entities and obtaining an IQueryable<T> object, this implementation transparently does the following:

CLIENT side:
- Expands the query expression tree to correctly manage lambda expressions.
- Parametrizes the query decoupling it from constant parameter values (in order to cache the query independently from it's parameters concrete values).
- Serializes the query to XML.
- Compresses the serialized query (optionally).
- Sends the query to the server (web service request).

SERVER side:
- Open the concrete ObjectContext.
- If not in cache, decompress and deserialize the parametrized query and put it in the cache, else get the already decompressed and deserialized query from cache. Caching is needed to prevent deserialization as much as possible, because expression deserialization is expensive (fortunately serialization is not).
- Deparametrize query (replace parameters with actual values).
- Execute the query.
- Return the resulting objects to client side (web service response).

This proved to be very useful in many projects and, In order to achieve it, a lot of effort is required, but it probably will become obsolete in EF 5.

Regards,

The current EDMX designer doesn't work well for enterprise scenarios - it becomes incredibly cumbersome as the number of entities grows. For example:
* It forces the developer to arrange entities visually - once you get over about 10 entities or complex relationships between them, it becomes difficult to do.
* It's difficult to find entities - rather than scan for them alphabetically, I need to scroll around a complex diagram I don't really want.
* The wizards get in the way - updating my model continually prompts me to modify my connection strings, I need to manually select the refresh tab for trivial database changes, and renaming database objects is incredibly difficult.
* I can't separate my "ORM structure" (EDMX) from my "entities". In the enterprise scenarios I'm working with, I need to put my POCO entities in a common class library and keep them structurally separate from the "database access logic".

At this point, it might be easy to suggest using Code First to working around this scenario - it allows me to declaratively describe my relationships through the fluent API and write my own POCO entities.

The problem is that there's a large performance hit with code first in complex scenarios - the lack of an EDMX means the model must be recreated each time the application is started. It also must look at the structure of the database itself, not just the code - meaning I take a large IO hit as well.

Our application has an SLA on request time - we simply can't wait 5-10 seconds for "code first" to build the model on the first request. IIS automatically recycles processes, meaning the performance hit comes up every 2-3 days. We want to keep app pool recycling in place for stability reasons.

What I've love to see is a "compiled database first" model - something where I can write my POCOs and Fluent API, then have EF pre-compile the EDMX rather than generate it at runtime.

Graphic designers, wizards, and auto-generated entities (ie/ current EDMX designer) are a deal-breaker for enterprise scenarios, but so is generating the complex model at runtime using Code First. No win.

When converting an existing system to Code First Migrations sometimes the schema is in an inconsistent state. In SQL we can handle this by testing for exists and only dropping if it does. I handled this in code by catching the exception when trying to drop a foreign key that doesn't happen to exist in the database being migrated. this works when run as part of the upgrade, but doesn't work when running the Update-Database Powershell command. Below I have copied the code and error message for some context.

try
{
this.DropForeignKey("EDWAdmin.MetadataTableNote", "FK_MetadataTableNote_MetadataTable",);
}
catch
{
//swallow the exception if the key can't be found
}

ALTER TABLE [EDWAdmin].[MetadataTableNote] DROP CONSTRAINT [FK_MetadataTableNote_MetadataTable]
System.Data.SqlClient.SqlException (0x80131904): 'FK_MetadataTableNote_MetadataTable' is not a constraint.
Could not drop constraint. See previous errors.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at System.Data.Entity.Migrations.DbMigrator.ExecuteSql(DbTransaction transaction, MigrationStatement migrationStatement)
at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.ExecuteSql(DbTransaction transaction, MigrationStatement migrationStatement)
at System.Data.Entity.Migrations.DbMigrator.ExecuteStatements(IEnumerable`1 migrationStatements)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.ExecuteStatements(IEnumerable`1 migrationStatements)
at System.Data.Entity.Migrations.DbMigrator.ExecuteOperations(String migrationId, XDocument targetModel, IEnumerable`1 operations, Boolean downgrading)
at System.Data.Entity.Migrations.DbMigrator.ApplyMigration(DbMigration migration, DbMigration lastMigration)
at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.ApplyMigration(DbMigration migration, DbMigration lastMigration)
at System.Data.Entity.Migrations.DbMigrator.Upgrade(IEnumerable`1 pendingMigrations, String targetMigrationId, String lastMigrationId)
at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.Upgrade(IEnumerable`1 pendingMigrations, String targetMigrationId, String lastMigrationId)
at System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.Update(String targetMigration)
at System.Data.Entity.Migrations.Design.ToolingFacade.UpdateRunner.RunCore()
at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.Run()
ClientConnectionId:9bbf8a57-be25-4268-add2-e2f9f3b652de
'FK_MetadataTableNote_MetadataTable' is not a constraint.
Could not drop constraint. See previous errors.

Some applications require the ability to maintain data in different languages. In relational databases, a common implementation pattern to achieve this is to use a main table for the corresponding business entity with all persistent properties mapped to table fields, and a language (or localization) table for the language dependent properties of the same business entity. A single instance of a language dependent business entity is therefore represented as a single record in the main table, and multiple records in the language table, depending on the number of supported languages.

It would be great when EF could support this pattern
- by creating the necessary tables and keys on schema creation
- managing inserts/updates and filling the entities with values of the current culture (or the fallback value of the main table) when selecting data

Make Entity Framework Fully Mockable and injectable

In general, mocking out the Entity Framework DAL is a big pain to accomplish. ObjectContext has no interface and the T4 templates aren't written to create interfaces for the objects they create.

This hampers good unit testing and makes them less injectable.

Put an interface on ObjectContext. Have the T4 Templates put interfaces around all of the objects that are generated and make sure that all objects used have interfaces so that mocking frameworks, like MOQ or Moles & Pex can automatically generate stubs to replace the objects in unit tests so that tests don't need to be tightly coupled to the database.