v2 Wish Lists - Add Yours Here


  • With the impending release of the Entity Framework I am reading a lot of comments from people who are already thinking towards the next release and its features. I know there are many people whom I have worked with who will not use the first version of the Entity Framework due to some features missing, and they are hoping that v2 is not far behind (or v1.5 Smile). So I thought perhaps it would be good to have a list of items that we would like to see in v2, from the forums participants.



    I'll start it off with a few, but I'd like to hear what everyone else wants, too. I have hard a lot of requests & concerns through email, conferences, user groups, and the forums ... so perhaps this is a good way to consolidate some requests for the Data Team.


    1. POCO support. Specifically I'd like to see it possible to have a business entity NOT have to implement an interface nor inherit from a base class to work with the EF. The problem my customers face for existing applicaitons is that they find the task of integrating EF with their models daunting. If EF supports POCO its much easier ot integrate.
    2. Support for enumerations to be fully supported.
    3. Improved SPROC support without requiring that foreign keys are updated in related models. A SPROC should not have to be changed to account for the conceptual model. i.e. a fictitious sproc like pr_Update_Order should just be updating the Order table and not also requiring the foreign key ID's to be involved.
    4. Perhaps an optional lazy loading switch that can be set on the Context when created that would tell all objects to load as needed (while connected/attached).


    There are more, but this is just a quick list to get started. The #1 priority IMO is POCO support.


    Friday, May 23, 2008 1:23 PM


  • Thanks for starting this thread, John. We appreciate this input, please keep the votes coming!
    Friday, May 23, 2008 5:13 PM

All replies

  • Also, be able to take the context internal and, why not, taking constructors private or protected or internal.

    Friday, May 23, 2008 2:50 PM
  • Personally, first and foremost I would like to see full support for enumerations, including designer support for generating enumerations from lookup tables specified by the user.

    2. Support for mapping sproc parameters to constant values.
    3. From what I've seen in the forum, support for associations from alternate keys and support for specifying alternate keys on an entity.

    Friday, May 23, 2008 4:02 PM
  • Thanks for starting this thread, John. We appreciate this input, please keep the votes coming!
    Friday, May 23, 2008 5:13 PM
  • Make ObjectStateEntries serializable so that if we WANT to serialize the state we have the option


    This also lets me write debugger visualizers instead of having to do a hack like this:


    Friday, May 23, 2008 6:36 PM
  • Something else I'd like to see added is discussed here and here.  Currently, a ScalarProperty and NavigationProperty can't both be added for the same column.  The error states that one value could be changed and not the other, causing a mismatch.  There are cases where we want to know the id but don't need the entire record, and there are workarounds to this right now, but nothing built-in.
    Friday, May 23, 2008 6:44 PM
  • Support for the new SQL 2008 Spatial data types Geometry and Geography


    Sunday, May 25, 2008 7:10 PM
  • I just marked this thread down as answered so that it doesn't distract as an unanswered question, but I do agree with Noam above: this is great data, please keep it coming.




    Sunday, May 25, 2008 11:54 PM
  • Some designer things that are probably already on your list, but just in case....


    Make it easier to create virtual tables in ssdl when we need them. Start by creating the Entity and then have an option to create a virtual table (and the mappings of course) based on the entity.


    Some things that LINQ to SQL's designer has that would be hugely helpful:

    *Smart pluralization

    *Automatic creation of entities (and their virtual tables and mappings) for REad Stored Procs.

    *Drag & drop objects from server explorer (ducking & running for cover)


    Designer support for Complex Types, Query Views, Defining QUeries (i"m sure you are just SHOCKED that I"m asking about these  )


    (There was a video of some ideas you were working on that had more tooling for SSDL. Is that coming?)


    There are a slew of pain points that are based on some strict rules for model validation. Obvously there are a LOT of dependencies in teh model and need for generalizations in order for EF to be able to handle so many scenarios, but if it's possible to relax some of these rules, it would be awesome:


    *Function mappings: don't force all or nothing on Insert/Update/Delete, don't require foreign keys where we don't want them (e.g.delete contact).


    I'll have to come back when I remember some of the others...


    I know you guys are thinking a lot about some way to generate sql from the model to create new tables, views, sprocs etc, so I won't mention that one. (Oh, I just did, sorry (heh)) In the meantime, we have the stuff that Ryan and Dave DeWinter did along these lines?


    Monday, May 26, 2008 12:33 AM
  • Here's my list, in order of desire...


    #1 Detachable graphs that maintain relations between entities.

    #2 Enumeration support

    #3 Ability to set generated values from designer (such as a datetime added by the db)

    #4 A real "where in" clause for LINQ support

    #5 Caching in-built to context



    Monday, May 26, 2008 2:21 AM
  • A twist on Brian's #1:  I would like to see a parameter added to detach that lets us explicitly say "yes pull the entire kit n' kaboodle out". It's a major behavioral change and would be dangerous to make this the default in v2 after pepole have gotten used to the fact that in order to protect the other change-tracked objects, only the specified object is detached.


    But this also reminds me...


    The current behavior of objects still being attached to a context even when the context is disposed is a really bad gotcha. I know that the reasons for this have been explained elsewhere in the forums (I may even have started the thread when I got bit by this) but still it is such unnatural and unexpected behavior, it would be great to have work in a more expected manner.



    Monday, May 26, 2008 2:30 AM
  • I'd like to see support for an entity-first workflow scenario. This would involve create an entity first (in code or with the class designer,but not necessarily the EF designer) -okay maybe second after a test, then associate it to the CDM, mapp it to the databae - or create a new table if it dosn't exist. This would have to be re-entrant - almost the opposite of Update Model from DB - say "Update Model from Classes".


    I think it would also imply that in combination with POCO, I could have my entities defined entirely outside of the designer.cs file created by the EDMX designer. Even going model first - it might be nice to instruct my entities to be generated in another assembly potentially.


    Barry Gervin


    Monday, May 26, 2008 5:22 AM
  • 1. 'Cascade delete' = deleting the 'main' entity to clear up the whole related graph.

    2. Default database field values imported into EF Model.

    3. Something like ApplyPropertyChanges but to apply to the full-graph, not piece by piece. Or, at least something that applies the changes on the Navigation properties too (add, remove the related entities).

    4. I would really like to never get an answer like: "This feature is supported by the engine but not by the designer". For a mature product I don't see a reason to have a tool (the designer) that does not support the whole product features. This could include something so we never have to edit the xml files from outside the designer.



    Monday, May 26, 2008 3:49 PM
  • A simple (but important) feature is a Serialization = True|False in the Type and Property properties sheets to control whether entire EntityTypes and individual properties are serialized. (How about this for v1?) LINQ to SQL has this property for members (still unidirectional in v1).


    Otherwise, you end up with manual edits every refresh.





    Monday, May 26, 2008 8:40 PM
  • In Visual designer add a possibility to map an entity to sproc to get data.

    Tuesday, May 27, 2008 8:33 PM
  • 1. ID columns. When two tables are related (eg. one to many Customer->Orders relationship on Customer.ID = Order.CustomerID), I REALLY need to have an Orders.CustomerID property without having to load the Orders.CustomerReference and use Order.Customer.ID. I really want the ability to set a reference by ID value only with no loading involved for performance.

    2. Partial validation and saving methods, just like Linq to SQL. Perfect for business logic. This is a glaring ommision in v1.

    3. Remove the sealed attribute from EntityDataSource, and allow overriding of its most useful methods.

    4. If an EntityDataSource returns zero entities, it is currently impossible to use an ASP.NET GridView/FormView bound to it (and probably other databound controls too) to add a new entity. The reason is that EntityDataSource returns a List<object> instead of a List<MyEntity>. The EntityDataSource should return an ITypedList or a List<MyEntity> or something, or perhaps the Selected event should allow me to modify the e.Result parameter so I can do it manually. Basically, you can't use an EntityDataSource to add the first entity to a collection via a databound control at the moment!!!

    5. I want enum support too.



    Wednesday, May 28, 2008 12:20 PM
  • It will be very useful to be able to define read-only fields that map to eSQL expressions in the model. For example, create a Invoice.Total field that maps to Sum(InvoiceLinePrice). This will be a huge improvement in the expresiveness of the model.

    Wednesday, May 28, 2008 12:46 PM


    1. I'd really like to see some way to tie in sync services to the model in some way. Imagine flagging specific entities to enable offline support. SSCE assembly references, SSCE db creation, would automatically be done for you. Sync Tables would be created based on the flagged entities. Basically start to tie the products together in a more consistent framework. Give us the ability to incorporate offline capabilities within our apps in a more declarative fashion. The details of how you sync is your business, what you sync is mine.


    2. Maybe a little too ambitious here but the ability to specify data source/provider/conn string details at the entity level within the SSDL. Something like this may be required to accomplish what’s described above. This also implies different types of data can be used together in the same Linq query (web service call results joined against Active Directory etc). Transaction support may be a real problem here J I thought this was an eventual aim of EF..


    3. Also the ability within the designer to break down the model into subject areas. Some of these diagrams are next to impossible to digest after 30 or so entities. When you highlight the relationships within the designer, don't choose dark grey, use something like red to really show us the related entities.


    4. QBE grid for linq to entities queries. Again , maybe not an EF suggestion but what the hell..


    5. An Easy Button , I double click, I go home Smile








    Wednesday, May 28, 2008 2:43 PM
  • Just a quick response to point #1: You can accomplish this today with EntityReference.EntityKey property.  You can get and set the key of the related entity in much the same way that you could manage a foreign key without loading the related entity.


    This isn't quite the same, and we're looking at ways to have more direct foreign-key-like properties in v2, but I just wanted to make sure you were aware that some of this can be done in v1.


    Wednesday, May 28, 2008 7:46 PM
  • This might be more of a general linq issue but a better multi row update and delete story. I would really like to be able to do something along the lines of the following:


    ctx.Phones.Where(p => p.Status == false).Delete();

    ctx.Phones.Delete(p => p.Staus == false);

    ctx.Phones.Where(p => p.Staus == true).UpdateSet(new { Status = false; }); // sets status to false where true.


    I could create extensoin methods to perform any of these but they are single row updates over the enumerations. I want something that performs these at the SQL level instead.


    The exact syntax is not critical but I find myself doing a lot of dynamic SQL when needing to update multiple records. An alternative is to write sprocs but I don't want to go down that path right now.






    Thursday, May 29, 2008 9:22 PM
    1. Enumerations - This should be in V1, not V2 but...
    2. The ability to build a class like a Winform/WPF form where the description of the object is in the xml file and the code is in the .cs file so that everything is encapsulated instead of one big huge mess file that can't be human edited unless you're superman.
    3. Editable class files like Winforms and WPF so that we can put real business logic in place.
    4. Better mapping interface. Tres confusing in the designer
    Thursday, May 29, 2008 11:17 PM

    Forgot a really important one!


    1. Easier to use/read/create linq for inner and outer joins.  I.e. add innerjoin and outerjoin properties. Then we can do left outer joins easier. It's a mess right now.
    Thursday, May 29, 2008 11:19 PM
  • More.


    These are brutal and prevent even the most basic business rules from being implimented:


    1. Fix the designer so that you can inherit from any object in the Assembly that impliments Entityobject or the interfaces. Otherwise we can't do business rules within the class.
    2. Make SaveChanges virtual so that we can override it and provide basic validation functionality. Right now it's impossible unless you want to throw errors on property changing events which is rediculous.
    3. Make SavingChanges event (if you must do it this way) Cancelable instead of requiring an error throw. Error throws are expensive. DO NOT USE THEM UNLESS ABSOLUTELY NECESSARY.
    4. Make PropertyChanging Cancelable. Error throws are expensive. DO NOT USE THEM UNLESS ABSOLUTELY NECESSARY.
    5. Give us real error reporting with IDataErrorInfo so that we can intelligently report to client applications.

    These together make Linq to Entities useless for all but the most basic scenarios and prevent business logic from being implimented intelligently because you can't guarantee that an object was validated before save, and throwing on property setters is a slow and rediculous way to do error handling.  They also make the process of validation incredibly slow and computationally expensive because of the requirement to throw errors instead of doing proper error handling that we've had since the very first days of .NET.


    Friday, May 30, 2008 3:05 PM
  • An "OnEntityMaterialized" event, taking the context it was just created in as EventArgs, in order to allow some kind of custom-initializiation (overwritting the constructor is not too useful, because it is not aware of the context).


    Friday, May 30, 2008 3:17 PM
    • Support for boolean comparisons other than Equals or Is Null for Conditions in a mapping. For example, support for Greater Than, Less Than or Equal, Like, Not Equal, etc..
    • Allow the column names specified in Condtions to be exposed as properties (currently a column can be either a ScalarProperty OR a Condition, not both). Make them read-only if necessary (i.e. so they don't invalidate the object type in the case of a condition that's acting on a column as a discriminator to qualify subclasses using the TPH inheritance model).
    • Allow for more complex conditions with multiple AND/OR'd predicates. For instance,
    Code Snippet

    <MappingFragment StoreEntitySet="PastEmployee" >
      <ScalarProperty Name="Id" ColumnName="emp_number" />
      <ScalarProperty Name="FullName" ColumnName="emp_full_name" />
      <ScalarProperty Name="Status" ColumnName="emp_status" />
      <Condition Value="emp_status == 'Resigned' OR emp_fired_date Is Not Null" />

    • Allow these to be configured through the designer in the Mappings Details window.
    Tuesday, June 03, 2008 5:31 AM

  • What I'd like to see:
    - automatically updating / inserting / deleting entities split across tables (parent-child)
    - in designer a simple way to get a denormalized entity based on two parent-child entities, with full support for updating / inserting / deletion. So simply select two entities related 1-* and right-click / Combine or something like that.
    Check the introduction I want something to select SalesPerson, Employee and Contact and have the SalesPerson entity created from these.

    Tuesday, June 03, 2008 6:52 AM
  • This should be in v1:

    - OnDelete: Cascade in the designer. This is an essential feature.

    - OnStateChanged event on EntityObject (to reflect this on UI).

    - Servergenerated value support in the designer.



    - Varbinary, image, filestream = streaming support with lazy (stream) loading / updating.

    - Lazy loading properties, property groups.

    - Complex, row type designer support.

    - Out-of-the-box WCF based disconnected support, ObjectContext without SQL Connection!

    - Domain object support! Split the EDM designer + code generator and mapping + SSDL designer.

    - Object first approach support.

    - SSDL designer as seen on an early video.

    - IDataErrorInfo, INotifyCollectionChanged on query result and on entity collection. Better WPF integration please (IBindingList doesn't even support client side sorting)!



    Tuesday, June 10, 2008 5:01 AM
  • Hi,


    I would really like to be able to specify extra entity 'Includes' when doing an EntityReference.Load(). Something like the following:


    Code Snippet


    School s = myContext.Schools.First();

    Class c = s.Classes.First().Include("Pupils");






    Tuesday, June 10, 2008 3:31 PM
  • You can already do this with a fairly small amount of code...  In your first case, realize that you are doing a LINQ to Objects operation which just takes the first entity from the in memory collection rather than actually querying the database.  So in that case you could just do two lines:


    Class c = s.Classes.First();



    For the second case, though, things are a little more interesting.  The way I'd do that is this:




    - Danny


    Wednesday, June 11, 2008 4:50 AM
  • The EntityDataSource is great but does not currently support the Unit of Work pattern, i.e. the user can make a number of changes to entities over postbacks before either saving or cancelling (Ok or Cancel button).


    It would be a big help if the EntityDataSource could support Unit of Work either out of the box or through customisation.




    Wednesday, June 11, 2008 7:52 AM


    That's an eye-opener but it is pretty dizzying.


    If there was a way to simplify that back down to Ben's suggestion:


    then it would be much more intuitive based on what we already know that would be great.

    I know Include is a method of a queryobject, so just have another Include method.


    Easy to suggest.Not sure about pulling it off.


    But while there are lots of neat tricks of ways to do things in EF, there are just too many nuances like this which are not discoverable.

    Wednesday, June 11, 2008 11:43 AM

    I'm sick of haivng to copy the connection string from my model project to a project that is referencing it. I forget about half the time and get an exception then think "oh yeah - the connection string" and have to go back to do that little task.


    It would be cool if there was a way to "copy connection string from. project X...." then I could point to the project, and the desiger would find the config file and copy the connection string into the config file (create it on the fly if necessary) of the currently selected project.

    Sunday, June 15, 2008 8:56 PM
  • First of all, whilst formally trained in Software Dev. and Information Systems, I currently have little experience within software development industry as a whole.  Please forgive me / correct me if my understanding of the Entity Framework and its' uses are missing "the point".


    Since there seem to be very few people talking about the "Model First" approach, I wanted to add here that, for me, developing software for a project without an existing database to leverage, providing the tools for a "Model First" approach would be very important. 


    Whilst I realize that we may be a bit behind the times by developing a new system from scratch, I believe that not providing this feature disadvantages new developers / new software.  The benefits of EF of course still make it worth designing the DB and using EF within our applications but I just figure that it would be "easier" to go from EDM to a Relational Database then the existing database first conversion.  Even a limited tool that couldn't implement foriegn keys / associations would be a start and take a lot of the "grunt work" out of the process.


    I suppose my problem here is that I'm confused as to where to start with the existing releases of the new technology mixed with the requirement for the database first.  Go through the design process for a relational DB and fit in with everyone else doing database first?  Design an EDM first and use this as the conceptual model for the design of a database manually?


    I appreciate that the "Database First" approach is what is required by the majority.  Correct me if I'm wrong, but once all the existing applications are ported, wouldn't the majorities' focus shift towards using EF for new applications and their associated databases or at least extending the capabilities (assuming the extensions are big enough to require database modifications) of their existing ones? 


    Tuesday, June 24, 2008 8:49 AM
  • Jazz127,


     We agree with you, and actually hear a lot of people talk about and ask for "Model First." We are investing a large amount of energy and thought into developing this feature for a future release as part of a greater artifact generation system.



    Tuesday, June 24, 2008 9:16 PM
  • A unique temporary entity key so you can easily distinguish between added entities of the same type within the framework (and don't need some kind of work around specific to the type you are dealing with).

    Thursday, July 10, 2008 8:21 PM

    1. For V2, PLEASE give us the ability to break down models into something that we can digest. Basically we should be able to organize types


     a. Visually inside the designer

     b. Physically, by assembly

     c. Logically, by namespace


    No more of this generate and throw everything into xxxDesigner.cs. (Really bad approach). Companies break their code down much differently than this..


    2. Rock Solid, High Quality Designer


    I seriously hope that the designer team understands that they have a critical piece. I think that alot of folks will be turned off if the V1 release has as many problems as what we have now. I see tons of weird mapping errors when we're doing simple things. I won't go into them here but it would be a real disappointment if we can't perform the basic , stated modeling scenarios without dropping into XML (Remember, we have to sell this internally to our teams so throw us a bone here!! I'll get shredded if I have to tell everyone that they need to become EDMX - XML Experts. )


    3. File Contention - Would be great if other dev teams  could work and extend a core set of models without alot of file contention.  Some have suggested multiple models but I see technical problems with this. A complete story for this in v2 would be nice.


    (Does MS read this stuff?)





    Thursday, July 10, 2008 9:13 PM
  • The EF does exactly this in v1 today.  If you add an entity to the context, then it automatically is assigned a unique temporary entity key.  When you save changes this key will be replaced by a permanent key.


    Given that you put this request in place, though, I'm guessing there are some scenarios that you are interested in that aren't working the way you would like.  Could you elaborate a bit more?

    Friday, July 11, 2008 5:09 AM

    While there is an EntityKEy, anything that makes it unique seems to be hidden from us.


    The scenario is that if some new entities are added and we don't happen to have tangible instances of them (myfirstNewEntity, mysecondNewEntity) how can we go find them in the context (eg GetOBjectbyKey)? And to make it worse, what if it's possible to edit those new entities before SaveChanges is called? THen we don't even have the ability to find the new entity whose firstname propert="John" nad lastname property = "Doe" because those could change.


    The way I had suggested was to be sure to have a guid or something in the entity that you could use for this purpose, but he is looking for a more generic solution. Maybe if you could expose whatever data it is that you use to keep track of the new entities that would be helpful. You must be getting at it in the EntityDataSource, but I've been poking around that with Reflector and can't see anything yet.

    Friday, July 11, 2008 12:24 PM
  • Right now easiest way to delete or update entity is to load it from DB first, which is an overhead, especially if you want to use EF in SOA.
    I understand that according to entity relations several ID's can be required to delete entity from DB or update it.

    Ok, so let me provide a list of required ID's, something that would serve like a key-value list where key specifies storage entity and ID identifies concrete entry in the storage.

    That list conceptually would be a token which you must provide in order to modify an entity. Strongly typed tokens can be generated by entity class generation tool. Or you can construct tokens yourself.

    To do that now, you must recreate entity hierarchy, set all required values and attach it to object context. That is an overhead. If deleting the entity means deleting an entry from joining table why should I create object representing joining table and set it's values? Why do I have to deal with objects representing joining tables at all? That only exposes DB normalization subtleties to my code. When I work with objects I want such subtleties be specified in some config file and smart ORM dealing with resolving impendency mismatches.

    That token can be as descriptor, list of prerequisites needed to update an entity. Perhaps DAL layer can know how to construct those tokens and provide it to EF to actually do all the mappings and generate all the sql.

    Introduction of those tokens would truly separate entity mapping part of EF from my domain classes. It would decouple relationships of my BOs from knowledge of how to persist them. My BOs can carry those tokens with them without caring about it (maybe by inheriting from layer supertype), perhaps my DAL layer knows how to extract that token from object and provide it to EF. Perhaps EF maps object instance to it's token. But separate and abstract info needed to map my BOs to storage schema.

    Object graph then represents changes; token is a descriptor which EF uses to do mappings to storage schema and persist those changes.

    Please let me know if I didn’t make myself clear or if I’m missing something from EF’s picture.


    Saturday, July 12, 2008 7:29 PM
  • Well the temporary entity key is our current mechanism for exactly this scenario.  It's very much like having a guid or something like that.  If there were a guid property, it wouldn't be set until you added the entity to the context, and then you would have to read that guid off the entity, store it somewhere and then use it to find the entity again later.  The temporary key gives you the exact same experience.  When you add an entity to the context, if the very next thing you do is copy off the entity key from the object you just added, then you can use that entitykey to look up the entity any time between then and when you next call SaveChanges.


    Of course there is an issue around the fact that when you call SaveChanges the temporary entitykeys will change to permanent ones and you will no longer be able to use that temp key to find the entity, but that leads me to my next point:


    If you are going to hold onto a reference to something, be it guid, temp key or whatever, why not just hold onto a reference to the added entity?  That will certainly stay valid across calling SaveChanges, etc.  Yes, this does mean you have to structure your code to allow you to hold a reference to something, but I really don't see any way to get around that no matter what you do--if your key values are generated on the server, then you won't be able to use them until after you save changes, and nothing but the key values provide guaranteed unique identity.  At the same time, if you are generating key values on the client, then you can just use them...


    - Danny

    Saturday, July 12, 2008 10:50 PM
  • Okay - I totally get it. The fact that I coulnd't actually see any values in the entitykey was confusing. "mrent" - does this make sense to you? If not, post something on your original thread so we don't bog down the wish list with this conversation.



    Sunday, July 13, 2008 1:37 AM
  • Make it possible to define the metadata from code.

    Tuesday, July 15, 2008 12:07 PM
  • I think it will be great to support this scenario.

    Moreover, I think it won't be hard to do it on the designer.

    The base entity type is abstract. Does she contains the EntityKey?

    • Yes: the EntitySet is on it.
    • No: the EntitySet is on children entity type

    Do I miss something about the difficulties to do it?


    Monday, July 21, 2008 8:42 AM
  • Null value support for complex type properties.


    (Hope this isn't a dupe.)





    Monday, July 21, 2008 4:29 PM
  • Support for spatial query again the geography/geometry data type of SqlServer 2008.


    Wednesday, July 23, 2008 1:36 PM
  • I think it should be great if you add the notion of entity interface type. (included in the designer).

    In fact, I want to be able to define an interface implemented by the entity types and to be able to define a relationship between entity type and entity interface type or between two entity interface types.


    Tuesday, July 29, 2008 3:17 PM
  • Ability to get entity Ghost by key which will be initialized on first access of any property EXCEPT EntityCollection properties.

    Something like Hibernate's proxies.

    But for gods sake, don't initialize collections on something like EntityCollection.Add() or EntityCollection.Remove() like Hibernate does.


    Tuesday, July 29, 2008 5:37 PM
  • While I do think that you guys should have been able to accomplish POCO support from the get-go since NHibernate provided you with the de-facto example, I am going to punt on that one for now.

    What I am really concerned with is the Entity Framework v1.5.  I only want one feature in this release - support for complex types using the designer.  Based on the high volume of feedback on this issue, I would think that this could be accomplished by December 1, 2008.

    No monster release, postpone work on v2, fix v1.  How is this so hard?!
    Tuesday, October 21, 2008 5:02 PM
  • The entity framework will ship with the next release of visual studio and .net framework.  We do not have any plan for an out of band 1.5 release.


    That said, your requested feature (complex types in the designer) is on the list of planned features for v2.


    - Danny


    Tuesday, October 21, 2008 5:23 PM
  • Easy :

    1. StoreGeneratedPattern="Identity" supported by designer
    2. <OnDelete Action="Cascade" /> supported by designer

    Less easy :

    1. Flag "Include DataMemberAttribute" on each entity properties (including relations) to customize if DataMemberAttribute sould be added or not. Plus, ability to remove DataMemberAttribute on "EntityKey" in EntityObject (OR a very easy POCO solution )
    2. Ability to CancelUpdates (without reloading or having to make a clone before editing, like in DataSets)
    3. and of course, re-attach of a graph of entities edited in a n-tiers architecture (using WCF)


    Tuesday, October 21, 2008 6:36 PM
  • My company is determining whether to move to the Entity Framework or continue with NHibernate.  Not being able to add complex types using the designer is too fundamental an omission to use the Entity Framework in its current state.

    Do you anticipate v2 being released in the first half of 2009?

    The quick release of patches is what makes your open source competitors appealing and in high demand.  I am not sure why MS does not adopt this approach, especially when critical functionality is missing.
    Tuesday, October 21, 2008 7:23 PM
  • - making a database as basis for the ORM designer obsolete means the desinger creates the db + maps it.
    - Proper forward/reverse engineering/mapping.
    - properties not existing in database should be removed automatically
    - EDModel should be updated automatically press ONE button so its one go
    - Make a createDatabase() method to easily copy the schema of an existing database.
    Tuesday, October 21, 2008 7:58 PM
  • Something that is really important to me is full backward support with the current Entity Framework version without having to deal with breaking changes. Easy conversion of V1 models to V1.5 or V2.

    Thursday, October 23, 2008 8:36 AM
  • Work with the WCF tools team to ensure that the WCFTestClient can display payloads that contain entities.

    Sunday, October 26, 2008 1:40 PM
  • Based on your lack of response to my question "Do you anticipate v2 being released in the first half of 2009?" we have decided to move forward with NHibernate 2.0.
    Monday, October 27, 2008 2:21 PM
  • The entity framework v2 is scheduled to release as part of the next major release of visual studio and the .net framework.  There is not yet an announced date, but it is unlikely that the final RTM of those products will be available in the first half of 2009 (betas yes, RTM no).


    - Danny

    Monday, October 27, 2008 2:27 PM
  • In Danny's first reply he says, "The entity framework will ship with the next release of visual studio and .net framework."


    So the question is really "will visual studio be released in the first half of 2009?"


    Since there hasn't even been a CTP released for VS.NEXT yet, the liklihood of VS being released in the first half of 2009 is pretty slim.


    Happy lazy loading and POCO'ing for now. :-)


    Monday, October 27, 2008 2:28 PM
  • LOL - looks like Danny and I wrote our replies at the same time.

    Monday, October 27, 2008 2:35 PM
  • Maybe I didn't get how to use EF correctly or using it according to the best practices but a RejectChanges functionality would be nice... 




    Monday, October 27, 2008 7:25 PM
  • POCO would be my #1 priority

    Instead of feature requests, I'd like to present some of the problems we've had with using EF in a production system.

    - Client-side change tracking
    - Having 700+ tables in the designer is a no-go. Please make a simple table-based editor for the *dl files that doesn't show a diagram.
    - Updating the model ruins previous work (The designer is broken. It deletes stuff from the SSDL that isn't even touched by the database changes.)
    - Foreign keys that point to a unique key (I don't know if this should necessarily be fixed, but it was a problem for us, with an old database that could not easily be changed)

    Generally speaking, better support for n-tier applications.
    Tuesday, October 28, 2008 1:03 PM

    That reminds me..


    It would be nice to assign a default value on the primary key of a navigation property.


    Example: I have a Customer entity and a CustomerType entity and I want all new customers to start out as Standard which = 1. Right now I have to apply that default by setting the CustomerTypeReference.EntityKey in SavingChanges.


    If there was a way to set the default for that (maybe limit it to entities that use a single property for their entity key) in the Customer.CustomerType navigation property in the model, that would very nice.


    #2) I may have added this already but ...


    When I am creating a new project and referencing another project that has the model, can you dig into the model project's connectionstring and grab the EntityConnection string and add it into my new project. I frequently forget this step and it's a PIA.

    Tuesday, October 28, 2008 1:12 PM
  • Hi,

    Speaking of POCOs and persistence ignorance, why don't you use Aspect Oriented Programming to define how unit of work should track entity changes instead of requiring to implement some interfaces or other cumbersome mechanisms?

    Tuesday, October 28, 2008 8:12 PM
  • Sharas

    I've made this same mistake before. By editing the subject of your entry, you changed the subject of the entire thread. COuld you edit your post and change the thread title back to " v2 Wish Lists - Add Yours Here"





    Tuesday, October 28, 2008 8:22 PM

    An other feature we would like to have :

    1- Make System.Data.Objects.DataClasses.EntityObject implements IDataErrorInfo

    2- Extend IDataErrorInfo to handle 3 message severities

    - Error (blocking)

    - Warning (confirmation neeeded)

    - Information (just an info)

    Thursday, November 06, 2008 2:05 PM
  • Your entities are partial so you can implement IDataErrorInfo yourself. Moreover, if you want to change the code of your entities or the base class, EF supports IPOCO.

    Moreover, EntityObject can't define itself the message to set for IDataErrorInfo. So what do you want to do exactly?


    Thursday, November 06, 2008 4:00 PM
  • In generated properties, the properties code is something like this:

    Code Snippet

    public string CompanyName




            return this._CompanyName;






            this._CompanyName = global::System.Data.Objects.DataClasses.StructuralObject.SetValidValue(value, false);





    partial void OnCompanyNameChanging(string value);

    partial void OnCompanyNameChanged();




    I think that in some scenarii, it should be interesting to have this:

    Code Snippet

    public string CompanyName




            string value = this._CompanyName;

            OnGetCompanyName(ref value);

            return value;




            this.OnCompanyNameChanging(ref value);


            this._CompanyName = global::System.Data.Objects.DataClasses.StructuralObject.SetValidValue(value, false);





    partial void OnGetCompanyName(ref string value);

    partial void OnCompanyNameChanging(ref string value);

    partial void OnCompanyNameChanged();



    Thursday, November 06, 2008 4:07 PM
  • I would love to see POCO, lazy loading, and proper support for the .Contains(...) and other "WHERE IN" clause methods. 
    Thursday, November 06, 2008 4:57 PM
  • Make associations optional in the VS EDM Designer.


    I have and want to retain foreign key constraints in my SQL Server schema, but I don't always want to model these as associations and navigation properties (which can be the source of a lot of complexity).


    I would like to be able to choose which items allow associations and the associations are only added to the EDM if both ends of the association allow it ... and also have the ability to just switch off associations alltogether. Where assocations are not allowed, the foreign key remains as a simple plain old foreign key property (int, string or maybe an EntityKey) and there is no reverse navigation property on the other end.


    Currently the designer does not allow deletion of navigation properties and I do not want to dig around in the Xml. I am limiting the modelling to what is supported to the designer only.





    Thursday, November 13, 2008 4:19 PM
  • Hi, Transaction Drill-Down for uptading or adding for Set of multiples Entitys without taking care of the Keys Generated, Linq to SQL Classes does it transparantelly


    Be Able to use the data loaded on the class as I want, I mean, for instance I got A model Where an entity has a relationship with its self, and It always loads unnecessarily data (related user), and of course be able to send the Id instead of loading the hole related entity. For Instance, A User table using a field to determine who created that User. Of course this could be Lazy Loading tweaking


    I wish that could be Arbitrary classes to load arbitrary out-of-context data using a multiple result set stored procedure


    When V2 finally releases it should comes with lots and lots of samples, no more of the old same samples that won't give the information needed to build a LOB application, but with different scenarios level 100 through 500, advanced binding, tweaking, configuration, etc.


    I would also Like to have the connnection string reunified once again, the metada of the model should be placed on related, ready-to-edit files instead of writing that wierd connection string, specially if you use modular design in your application


    Thanks, V2 with all the proposed features would be very cool, I wish v1 realease had been as good as V2 is planned to be So I didn't have to waste this much time learning this so inmature tecnology. I had to switch again to old school programming to meet my requirements, may be on my software next version



    Wednesday, November 19, 2008 2:28 PM
  • The ability to add custom attributes to Properties. Right now we can do it to on the class level with another partial class definition but cannot do it to the Property level.
    Sunday, November 30, 2008 9:14 PM
    1. Generate database backend from an entity model.
    2. Create base interfaces for entities, so you can reuse the same type for multiple databases (as in sql, sqlce, mysql).
    3. Create both a Scalar and Association property for the same thing.  So have both PersonId and Person.  And keep them in sync.
    4. Support for a rowversion type that gets updated automatically when the db's rowversion changes on an insert/update.
    Monday, December 01, 2008 2:13 AM
  • Some responses to your points/requests:


    1. Already in plan for v2.

    2. I'm not sure I understand this one completely.  You can already use the exact same types against multiple databases just by changing the mapping, the SSDL and the store connection string.  It's not clear to me how interfaces would help here.  That said, if you do want interfaces, that will be fairly easy to add in v2 since we're moving to template-based codegen which is easy to customize.

    3. This is something we're considering, but I'm not sure if it will make it for v2 or not.

    4. This is already supported in v1.  You just need to set the StoreGeneratedProperty attribute in the SSDL to Computed on the relevant property.


    - Danny

    Monday, December 01, 2008 2:24 AM
  • - I want more feature in the designer (i.e. select entity to wiew, grouping ad create view of entity, enable master-detail association, more speed) 

    - I want to work in separate .edmx (one for each class of my app, with references between them) that collapse in a single .edmx when I compile. So I can use a single context with all classes

    - I want the ability to call the following events:

    • before read
    • after read
    • before write
    • after write
    • before modify
    • after modify
    • before cancel
    • after cancel
    • before attribute reading
    • after attribute reading

     simply whith partial class in single class of my context. So I put the Business Logic in each which inherith from entity.

    - I want to add siply the default value of each field.


    thank you

    I hope that I'll find them under my christmas tree. Wink

    Wednesday, December 10, 2008 4:31 PM
  • Not much i can add here, but better BindingSource = EF integration for WinForms devs, current one is pain. And an EntityState.AddedModified to check if added entity is changed since it was added to context.
    Wednesday, January 14, 2009 2:28 PM

  • 0. Support for SP|functions. Select SP's. Mapping inside designer. No need to create stub entities neither open direct access to a data tables. Ability to map to partially set of isnsert|update|delete stored procedues. Hey, we USE SP. We like it. We don't go to replace them by ad-hoc sql. There are a lot of reason to do so. Plese, don't leave us! Please! :)

    1.  Fix the issues listed at

    2. Precompiled context to reduce context load and construction time.

    3. Designer-generated context constructors accepting DbFactory and db connection string - or just DbConnection-derived object. It isn't easy to proper construct entity connection. No one usually interesting in providing correct model resource path - it should be designer work. Don't hardcode db-connection string inside metadata - it's bad decision.

    4. Possibility to do complex validation over entire context on attaching/deleting objects.

    5. Possibility to cancel changes without throwing an exception.

    6. An concept of source (something alike DataTable) for binding scenarios. Offline sorting, filtering, LINQ over them. Effective search. Local indexes? Ability to keep multiple views with different filtering/sorting over one source.

    7. Ability to do multiple undo|redo over sets of changes.

    8. Full-featured designer.

    9. Ability to dynamically change database connection string of the context // did I miss something?

    A. Ability to work with more than one database server inside the context. The same as with datasets. As for me, datasets ideology with separating model from datasource is more effective and useful in real-life scenarios.

    B. Partially offtop: regulary updating list of things being realized in v2|being approved to realize. Any reaction on our suggestions - accepted/rejected/f*ck off?

    C. Ability to run custom actions while filling objects/saving changes. As stupid sample - passing stream from websource to a database's filestream

    Thursday, January 15, 2009 5:45 AM
  • Warren W_ said:

    I would love to see POCO, lazy loading, and proper support for the .Contains(...) and other "WHERE IN" clause methods. 

    Thursday, January 15, 2009 9:06 AM
  • Features:
    N-Tier support

    - Extended properties (To be used by custom code generator)
    - Ability to refer to entity defined in another edmx

    Code generator:
    - Access to the CodeCompileUnit before it is written in a TextWriter.  It also us to modify as we wish the output.  I did it with the dataset generator.  The dataset generator had a public method that accepter my CodeCompileUnit as input.
    - Specifying the base class by other mean than providing a Type, should be a CodeTypeReferenceExpression.  This to be able to have a base class that has just been generated by the generator.

    Thursday, January 15, 2009 8:26 PM
  • Be able to add at least one customized super parent virtual ENTITY with some virtual properties for every entity generated. Here, virtual entity and/or virtual properties mean that they do not map to any data store directly. Currently, the workabound is to add those common properties as each partial class even they are exactly same to all of entities. For instance, we have to create forty partial classes if we have forty entities now. If we can generate entity with a base class, then we can put all of common properties into this base class.

    Thursday, April 09, 2009 9:21 PM
  • You should consider implementing the idbag (a NHibernate term). It'a a many-to-many collection with an additional surrogate primary key. Main benefit of this kind of a collection is a big performance boost (for instance deleting just one element is done by pointing particular key).

    I also wish I could split the designed model to separate diagrams, it would be easier to read and modify.
    Monday, April 20, 2009 1:58 PM
  • The EntityConnection class exposes a StoreConnection property.

    It would be rather useful if the EntityTransaction class would similarly expose a StoreTransaction property.


    Friday, May 15, 2009 12:10 PM
  • Features:
    Context thread safe.
    - Andrea Bianchi - site:
    Friday, May 15, 2009 1:09 PM
  • Hi,

    I am working on a DSL with the DSL-Tools for modelling POCO like Domain-Models. For the Data-Access I want to use the Entityframework Designer. Now with Visual Studio 2010 Beta 1 different Models can interact with each other, using the ModelBus. A DSL author can choose to generate a Modelbus Adapter, that will expose the model to other models or tools ( Is it possible, that the EntityDesigner exposes his model with a Modelbus Adapter in the next release. It would be very helpful, because than we could reuse the EntityDesigner.


    Monday, June 15, 2009 11:49 AM
  • The following would be helpful additions to the Visual Editor:

     - If you delete a entity from the C-Side, allow the developer to choose the table from the S-Side and re-add an entity to the IDE.

    - If a developer chooses two tables with a relationship, the IDE adds a relation and navigation properties.  However, if the developer deletes the relationship, it is re-added the next time the model is updated from the database.  For reference type tables (i.e. PaymentType) we cache their contents and have no need for them to be added with a direct relationship.

    Monday, June 29, 2009 5:16 PM
  • Support for SQL 2008 spatial data types in Linq and EF! Please!!!
    Sunday, April 11, 2010 4:16 AM
  • In the designer:  When you update from database, have a checkbox next to each table/view that you want to refresh.  This will allow you to refresh only specific database objects, not everything in an all or nothing manner.  This would prevent modifications from being overwritten.  When I update from the database, I normally just want to update one specific table or view, not everything automatically.


    Sunday, June 13, 2010 7:16 PM

  • 0. Support for SP|functions. Select SP's. Mapping inside designer. No need to create stub entities neither open direct access to a data tables. Ability to map to partially set of isnsert|update|delete stored procedues. Hey, we USE SP. We like it. We don't go to replace them by ad-hoc sql. There are a lot of reason to do so. Plese, don't leave us! Please! :)


    My concerns all center around SP support. Lack of full support for Get SPs is currently crippling me.

    1. I'd like for it to treat Get SPs just like it does tables and views as far as declaring Entities.

    2. I'd like to be able to add an SP as a property to an Entity with the IN parameters of the SP having the capability of being mapped to fields in the existing Entity. 

    Example: I have a stored procedure to GetAllCustomers_sp that takes no parameters and returns a Customer Entities (Requires Request 1 or jimmy-rigging). I'd like there to be an Orders Property on the Customer Entity that ties to GetOrdersByCustomer_sp which takes @CustomerID as input. I would like to be able to map Customer.CustomerID to @CustomerID, so I when I try to access the property Customer.Orders it doesn't need any further information from me to properly pull the data.

    As far as I know, these are my requests. I have seen many workarounds for Get SP support, but none of them are going to be suitable for regular use. I spent so much time in my past refactoring Datasets manually because of this, that, or the other problem. I'm really looking forward to working with Entity Framework, but I am unable to utilize all of the new features it has because of my strong tie to Stored Procedures.



    Monday, November 08, 2010 5:51 PM
  • In the designer:  When you update from database, have a checkbox next to each table/view that you want to refresh.  This will allow you to refresh only specific database objects, not everything in an all or nothing manner.  This would prevent modifications from being overwritten.  When I update from the database, I normally just want to update one specific table or view, not everything automatically.


    This is maybe a late reply, but there are 3rd party tools that add that to the designer. One such tool is the 'model comparer' in my add-in for Visual Studio, Huagati DBML/EDMX Tools. It shows diffs between DB ⇔ SSDL ⇔ CSDL in treeviews with checkboxes and allow you to select individual changes that you want to bring across to the next layer.

    I have posted a screencast and other info showing what it can do here:

    ...and if you want to take it for a test-spin you can download the add-in from and get a trial license from the same site.

       Cool tools for Linq-to-SQL and Entity Framework 4: - Rule based class and property naming, Compare and Sync model <=> DB, Sync SSDL <=> CSDL (EF4) - Query profiler for Linq-to-SQL and Entity Framework v4
    Tuesday, November 09, 2010 12:32 AM
  • thanks, I will check that out.


    Tuesday, November 09, 2010 1:22 AM