Using triggers for cascade delete/set allows for multiple cascades on the same table where the built-in sql server cascade does not

support EF for dynamic mapping at runtime via a strait-forward API for creating a table and map it to model (for Code First). this is useful for Enterprise level application such as BPMS, Felixble CMS and ...

Sometimes we find ourselves fighting against EF's algorithm for Insert/Update statements. It doesn't always get it right, or we just want more control, which is when it would be useful to override or give "hints" to it on what should be done.

I want to call LINQ to SQL wizard on click of button click. On the click of the button the LINQ to SQL wizard will be shown from which I can generate .dbml programmatically at runtime. Same scenario I want on Entity Framework also. I think there should be provision to call EF and LINQ wizard programmatically, so that I can genrate .dbml or .edmx file on runtime

I would like to see the T-SQL MERGE statement supported. For multi threading situations it really would be useful.

The Query method on the DbCollectionEntry and DbReferenceEntry classes provides access to the underlying query that the Entity Framework uses when loading related entities. A similar Query method should be added to DbEntityEntry.

Provide the ability to search the Entity Model from within the Visual Studio Entity Model Designer. Currently, in order to find an entity, one must scroll and navigate all over the place. If there was a search box that could take you directly to the entity, it would save TONS of time, especially if you have a lot of tables to sift through.

Allow a Select with UpdLock which locks all returned entities in the Database. This is a basic requirement to program for example a ticket sales portal with entity framework! So far it's not possible and I still have to stick to NHibernate :(

I'd love a tool for upgrading the model from version 1 to version 4.

Currently, EF uses a flat query in order to populate navigation property values when using eager loading via the Include statement. While this is acceptable in some (perhaps many) cases, there are a lot of cases where this produces unacceptable queries, whether from a size or performance perspective.

While this performance bottleneck can be partially avoided by using LoadProperty, this is

a) less expressive and more verbose
b) potentially more expensive, as it requires a round-trip for every property on every entity

Instead, please allow us the option of having EF generate multiple SELECT statements to address each navigation property

Support of common transaction to execute data modification instructions natively in the entity context across two or more tables in the model

SaveChanges on the ObjectSet is such a black hole... it would nice to be able to take more control over the process. Especially as an architect trying to create an architecture around EF...

Some tables have more than one field included in primary key.

This makes definition of generic methods that search by key hard to implement.

If it would be possible to combine all database keys into one struct in model, and enable T4 templates to recognize which property is the key, template-generated repository could be much more powerful.

Stored Procs need to be accessable from DomainServices. From ObjectContext, Where clause besides for .Equals and .StartsWith range testing and >= and <= are needed. Querying on dates is an absolute necessity in LOB apps. Dates in the Equals clause currently throw an error! Procs offer the ability to Join tables.

Like the TPT improvements, seeing improvements to concrete types would be great.