locked
Still No Enum Support? RRS feed

  • Question

  • Code-First is really what the ADO.NET Team should have designed from the outset.  I have been exploring it for the past couple days and the design is very encouraging.  Your team should (finally) be proud. :)

    Although... the lack of Enum support is baffling.  This has been missing for YEARS and we keep being told it's "coming."  It seems like such an easy feature to implement.  What gives?

    Well, in any case, no more evil EDMX files so that should quell our complaining for a bit.  Great job on this...  Looking forward to the next release (with Enum support ;))!

    Friday, January 21, 2011 7:12 PM

Answers

  • Hello all,

    Thanks for the continued feedback on Enums!

    Rest assured that the product team knows that Enums is a much appreciated feature, and we are currently working on the implementation and testing of it.

    We indeed want the use of Enums in EF to become pretty straightforward, like in the simple LINQ query above; you should be able to define a property in your entity that is of an enum type and then refer to it in queries. In fact, you should be able to do a myriad of other simple things with Enums in EF and it should all be very easy.  

    From the perspective of the changes that we need to make to the product in order to add support for Enums, it is not that straightforward. We are talking about adding support for a new kind of type, which happens to touch every single component in EF and needs to work nicely with every other existing and new feature.

    As it is always the case, the engineering work involves not only the implementation but also functional and performance testing.

    Here is a high level detail of some of the things we need to do (usual caveats apply, i.e. you shouldn't interpret any of this as a promise):

    1.       Design

    a.       Define enums for all EDM-related technologies (including OData which has implementations that are not even .NET based)

    b.      Define support for underlying and store types, supported operators (i.e. arithmetic, comparison, bitwise), operator semantics (they are not the same in C# and VB), etc.

    2.       Tooling

    a.       Database-first and model-first experience for Enums

    3.       Metadata

    a.       Add EnumType to internal metadata model and metadata API

    b.      Updates to XSD schemas

    c.       Add method to get CLR type for an Enum

    4.       Query pipeline

    a.       Updates to command trees and plan compiler

    b.      Updates to LINQ to Entities

    c.       Updates to Entity SQL parser

    d.      ObjectQuery/ObjectParameter updates

    5.       Mapping

    a.       Conceptual-to-Storage mapping

    b.      Convention-based (POCO) Object-to-Conceptual mapping

    c.       Attribute-based (EntityObject) Object-to-Conceptual mapping

    d.      Client view generation changes

    6.       Object services

    a.       Change tracking updates

    b.      Identity resolution updates (enums can participate in keys)

    c.       Relationship fix-up updates

    d.      Proxy generation updates

    e.      Update pipeline updates

    7.       Code-generation updates

    a.       EntityObject template and EDMGen

    b.      POCO template

    c.       Self-Tracking Entities template

    d.      DbContext template

    8.       Code-first

    a.       Property configuration

    b.      Convention updates

    c.       Etc.

    9.       Functions and stored procedure updates

    10.   Cross-feature work to make sure Enums work with other existing features

    a.       Concurrency management

    b.      Conceptual-side discriminators

    c.       Databinding

    d.      Default values

    e.      EntityDataSource

    f.        Serialization

    g.       N-Tier API

    h.      Validation

    11.   Cross-feature work with new features

    a.       Table-Valued Functions

    b.      Etc. (more to be announced J)

    12.   Coordinating with other teams  to make sure Enums support shines everywhere  

    a.       WCF Data Services

    b.      ASP.NET

    c.       RIA Services

    d.      LightSwitch

    e.      Etc.

    Hope this helps put the work in perspective.

    Thanks,

    Diego


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, February 1, 2011 11:44 PM
    Moderator

All replies

  • Hi,

    Enums won't be in the upcoming RTM because they require changes to core EF components (our first RTM of Code First builds on top of the existing EF4 components).

    Our team is working on adding emun support to core EF at the moment though :)

    ~Rowan

    Friday, January 21, 2011 9:51 PM
    Moderator
  • No Enum support in RTM? That's a bit disappointing, to be honest. I'm aware that this is due mostly to a lack of support in the EFv4 core, but I'm a little peeved that it's gone this long unsupported (3+ years now?). If enums are not going to be supported in RTM.. when? Service Pack 1? Any suggestions what to do in the meantime though?
    Friday, January 28, 2011 5:04 PM
  • This is pretty disappointing to hear this.  Based on previous ASP.NET release cycles.  We are talking atleast another year until we can expect this feature.  I don't see how difficult it can be.  All i'd like to do is be able to say:

    context.MyTable.Where(r => r.EnumField == MyEnum.Value1);

    Where MyEnum is defined as:

    public enum MyEnum {
        Value1 = 1,
        Value2 = 2
    }

    If the EnumField is an integer it would simply cast MyEnum.Value to int.  I don't get the complication in this.

    Monday, January 31, 2011 8:20 AM
  • No Enum support in RTM? That's a bit disappointing, to be honest. I'm aware that this is due mostly to a lack of support in the EFv4 core, but I'm a little peeved that it's gone this long unsupported (3+ years now?). If enums are not going to be supported in RTM.. when? Service Pack 1? Any suggestions what to do in the meantime though?

    I think it will be supported at .NET 5 =/

    In my opinion EF should release like ASP.NET MVC. A independent assembly with short relases. Not coupled with .NET Framework. And if it was Open Source, would be perfect


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4
    Monday, January 31, 2011 11:35 AM
  • Felipe - i agree with you on that! The ASP.NET MVC team has been awesome with their (relatively) short release cycles and making sure they have a seperate dll / dll's.

    Mind you - the CTP5 has it's own dll also ... so what's the diff? I think it's how it's possibly so tightly coupled to .NET4. I mean, that's awesome if it works .. but it sounds like adding Enum's means some serious changes to some existing .NET framework plumbing .. which is not going to happen. So could we not rely on that and move the new code into it's own dll?

    I've got the feeling, Felipe  .. that there's so much integration with .NET 4 framework (as expected) that the required changes would be in numerous spots ... that before you know it, the new dll's will be huge or so many of them, etc.

     

    I just wish we could get smaller changes, but more often. I'm guessing they don't do that because there's so much cost required to test test document and test and then support (phone, etc) .. that it would be ridiculous.

    Maybe things will get easier with the next release of EF after this current CTP goes RTM. So EF5? At least we're getting closer with each month to a mature product.

    There's still plenty of work to be done, so I hope the effort won't stop and we'll get things quickly :) here's hoping, mate :)


    -Pure Krome-
    Monday, January 31, 2011 12:26 PM
  • Pure Krome,

    CTP5 isn´t Entity Framework, is Code First CTP5.

    The Entity Framework, the core is System.Data.Entity. This CTP is like a wrapper.

    Because of this, to support Enums need a update at System.Data.Entity. I think that Enums that comes with .NET 5 or some .NET 4.5....


    http://blog.fujiy.net/ - MCPD em .NET 2.0 MCTS em .NET 4
    Monday, January 31, 2011 12:37 PM
  • I guess I'm more taken back by the technical challenge of implementing Enums.  It just seems so simple/straightforward (like a day's worth of work?  A week, at most?) that I have a very hard time understanding why it's taken 3 years of "we'll get to it."  It's saving an int to a storage mechanism, unless I am missing something completely obvious (and I do, from time to time).

    Monday, January 31, 2011 3:18 PM
  • Hello all,

    Thanks for the continued feedback on Enums!

    Rest assured that the product team knows that Enums is a much appreciated feature, and we are currently working on the implementation and testing of it.

    We indeed want the use of Enums in EF to become pretty straightforward, like in the simple LINQ query above; you should be able to define a property in your entity that is of an enum type and then refer to it in queries. In fact, you should be able to do a myriad of other simple things with Enums in EF and it should all be very easy.  

    From the perspective of the changes that we need to make to the product in order to add support for Enums, it is not that straightforward. We are talking about adding support for a new kind of type, which happens to touch every single component in EF and needs to work nicely with every other existing and new feature.

    As it is always the case, the engineering work involves not only the implementation but also functional and performance testing.

    Here is a high level detail of some of the things we need to do (usual caveats apply, i.e. you shouldn't interpret any of this as a promise):

    1.       Design

    a.       Define enums for all EDM-related technologies (including OData which has implementations that are not even .NET based)

    b.      Define support for underlying and store types, supported operators (i.e. arithmetic, comparison, bitwise), operator semantics (they are not the same in C# and VB), etc.

    2.       Tooling

    a.       Database-first and model-first experience for Enums

    3.       Metadata

    a.       Add EnumType to internal metadata model and metadata API

    b.      Updates to XSD schemas

    c.       Add method to get CLR type for an Enum

    4.       Query pipeline

    a.       Updates to command trees and plan compiler

    b.      Updates to LINQ to Entities

    c.       Updates to Entity SQL parser

    d.      ObjectQuery/ObjectParameter updates

    5.       Mapping

    a.       Conceptual-to-Storage mapping

    b.      Convention-based (POCO) Object-to-Conceptual mapping

    c.       Attribute-based (EntityObject) Object-to-Conceptual mapping

    d.      Client view generation changes

    6.       Object services

    a.       Change tracking updates

    b.      Identity resolution updates (enums can participate in keys)

    c.       Relationship fix-up updates

    d.      Proxy generation updates

    e.      Update pipeline updates

    7.       Code-generation updates

    a.       EntityObject template and EDMGen

    b.      POCO template

    c.       Self-Tracking Entities template

    d.      DbContext template

    8.       Code-first

    a.       Property configuration

    b.      Convention updates

    c.       Etc.

    9.       Functions and stored procedure updates

    10.   Cross-feature work to make sure Enums work with other existing features

    a.       Concurrency management

    b.      Conceptual-side discriminators

    c.       Databinding

    d.      Default values

    e.      EntityDataSource

    f.        Serialization

    g.       N-Tier API

    h.      Validation

    11.   Cross-feature work with new features

    a.       Table-Valued Functions

    b.      Etc. (more to be announced J)

    12.   Coordinating with other teams  to make sure Enums support shines everywhere  

    a.       WCF Data Services

    b.      ASP.NET

    c.       RIA Services

    d.      LightSwitch

    e.      Etc.

    Hope this helps put the work in perspective.

    Thanks,

    Diego


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, February 1, 2011 11:44 PM
    Moderator
  • Hi Michael,
    If you are using Code First + Configuration you can store the underlying int and expose the Enum in your class like so:

    public enum Alignment{ NotSet = 0, Left = 1, Right = 2, Centered = 3}
    
    public class Content 
    {
     internal int AlignmentInternal { get; set; }
    
     public Alignment Alignment 
     {
       get { return (Alignment) this.AlignmentInternal;}
       set { this.AlignmentInternal = (int)value;}
     }
    }
    
    public class ContentConfiguration : EntityTypeConfiguration<Content>{
     public ContentConfiguration() {
      this.Ignore(x => x.Alignment);
      this.Property(x => x.AlignmentInternal).HasColumnName("Alignment");
     }
    }
    

    This way EF is happy because it doesn't need to know anything about enums and the programmer is happy as he doesn't need to work with the 'magic numbers'. Only downside is you will need to setup and register the EntityTypeConfiguration as I have not found any other way to provide a simular working experience.

    Ciao,
    Elmar


    Imagination is more important than knowledge
    Wednesday, February 2, 2011 7:32 AM
  • Hello Elmar,

    Thanks for mentioning this workaround. This is actually a relatively simple thing you can do that can be useful in some cases. However, it has some limitations, e.g. you cannot reference the property that you expose as an enum in LINQ to Entities queries, because EF doesn't know about the existence and the meaning of that property (the code that computes the conversion gets compiled into opaque IL and not into LINQ expression trees that LINQ to Entities could understand). Therefore, you cannot write a query like this and execute it on the server:

    var leftAlignedContents =
        from c in context.Contents
        where c.Alignment == Aligment.Left
        select c;

    You can still apply other workarounds on top of yours to make this possible, e.g:

    a. Bring all the entities into the client's memory, then use a LINQ to Objects query to filter. The problem with this approach is that is much less efficient.

    b. Perform the conversion using LINQ expression trees, i.e. as demonstrated in Damien Guard's blog post here: http://damieng.com/blog/2009/06/24/client-side-properties-and-any-remote-linq-provider. This is a really neat approach but the problem with it is that it is not as straightforward as it should be. 

    As I said before our goal is  to make using enums really simple, but that will have to wait until the next full release of EF.

    Thanks,

    Diego


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, February 2, 2011 7:54 AM
    Moderator