Simple type mapping or mapped type conversion support
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.
While EF's support for integer-valued enums is a good step, integer values lose their meaning once they hit the database.
For example, if I have a table called "CustomerOrder", it might have a column called Status that indicates whether the order has been confirmed, shipped, etc. Keeping my knowledge of EF out of the picture, I'd declare this column as a char(1) with a constraint on the values that are valid.
Looking at EF, I'd want to be able to support enums in the query and in using the business object. I could use an enum currently, but that would mean I'd have to use an integer and lose meaningfulness as the value hits the database. If I come back in 6 months, I'd want the values in the column to be intuitive, rather than forcing me to go look at how I defined the enum in EF to see what the value for "Shipped" is in the database.
Ideally, I'd like to be able to define a mapping in EF to say that "O" means Open, "C" means Confirmed, "S" means Shipped, etc.
It's possible to do this now by leaving the string property alone, then defining another property using a char-valued enum in a partial class, but this property can't be used in queries and just clutters things up with two properties that mean the same thing.
Please support char-valued enums!
There are a number of scenarios where it would be helpful to be able to perform simple conversions or transformations to the values as part of the mapping process. Here are some real world use cases:
- A legacy DB with a schema that I can't change used a SQL byte type (instead of bit) to store logical boolean values. Current versions of EF don't allow me to coerce that field into a boolean type.
- Another DB stores monetary values in an int column as pennies, but I want the data model to expose these fields to callers as dollars through a decimal field. A simple multiply or divide by 100 is needed during the mapping process.
Support custom type serialization / deserialization in the same way you can with IUserType in NHibernate.
For instance, allowing a "Money" type to be created from a "Currency" and a "Value" column.
Or a Uri type to be created from a string-based column with some custom processing.
We plan to implement type conversions in the EF Core codebase. It is not committed to be part of 1.1 although it is one of three post-1.1 features we will start working on soon. See https://blogs.msdn.microsoft.com/dotnet/2016/07/29/entity-framework-core-1-1-plans/ for more details on 1.1 priorities. Also the bug tracking this work is https://github.com/aspnet/EntityFramework/issues/242.
Mikkel Lund commented
Is this coming to EF6? We really need an easy way to work with NodaTime in legacy databases.
@Dirk Watkins: enums mapped to a table would not be part of the *simple* type mappings and type conversions feature we have planned. Consider voting for https://data.uservoice.com/admin/forums/72025-entity-framework-feature-suggestions/suggestions/2683498.
Dirk Watkins commented
Enum to a lookup DB table please, with a nice display name column based on the Description attribute.
Arh, finally some light at the end of the tunnel! NodaTime will be much easier to use. TimeSpan >24h duration can be solved. Proper domain models can be based directly on entity classes without sacrificing clarity. Custom value types can be used directly in entity classes. The world will be a better place when issue 242 finally gets resolved :)
@Diego any updates? As @Dan mentioned I'd also would be happy to have this as a build-in feature.
@Diego Vega, can you update us on the progress of this? We've passed the 4-year anniversary of this request, which is now the 3rd most popular on UserVoice. Not having this feature is causing a lot of pain. I hope this has finally become a priority for your team. Thank you!
Aron Tsang commented
I hope you reconsider your stance on this feature. As it stands OData4/EF is broken. The OData team are pushing for usage of Microsoft.OData.Edm.Library.Date (whilst dropping support for DateTime) whilst your team are quite frankly refusing to support deserialization of DbDate to anything except DateTime.
It seems like your two teams are giving conflicting response, when the OData project lives and dies on EF support.
Matt Johnson commented
FYI - I think this is being tracked here: https://github.com/aspnet/EntityFramework/issues/242
Mark Junker commented
I'd really like to see a full featured type conversion API like the one from NHibernate which is just done right.
Nathan Alden, Sr. commented
A feature to map enums to and from strings in the database is very important when dealing with PostgreSQL custom enum types, which may be represented as strings.
Zackary Geers commented
This is a major feature for several database designs I've worked with, I'd really love to see this back in the queue. It will provide a lot more flexibility in working with legacy databases, and improve the ability to transition from other products onto EF.
bill darcy commented
i'm hoping for simple mapping of values in a database lookup table to an enum or any other structure (e.g. Dictionary) so that my code is always in sync with the values in the database table. if this were initially limited to an int and nvarchar columns, that would be a huge benefit.
Matt Johnson commented
A very clear example of why this would be useful can be found when considering libraries like Noda Time. Currently, it's impossible to directly map a Noda Time type (such as Instant, LocalDate, etc) to a database field.
"Planned" makes *much* more sense than "no status" (and is a huge relief). Thank you for clarifying!
Just to add some clarification around the recent change back to "no status".
Type conversion is something that we do plan to implement on the EF7 code base, and we're building out the architecture with this (and many other improvements) in mind. We're just changing the status to reflect that we aren't actively implementing this feature at the moment.
Mike Cole commented
See response: https://twitter.com/colemike/status/490135965025841155
I'm completely gobsmacked. This is the fourth highest rated feature request on the list. We have been waiting for this for *years*. And now you are downgrading it to "no status"? It's not like "under review" was all that strong of a statement to begin with, but it least it was something. At the very least, could you communicate why this feature is not worthy of implementing in the very near future? Clearly, a lot of people are very anxious to have it. Thanks.
Frank Quednau commented
I am surprised that such a useful and important feature that doesn't seem desperately complicated doesn't get a higher priority.
Marc Lewandowski commented
What features are beating this out? This missing feature is a ral doozy. Please consider this feature, soon.
I hate stumbling upon limitations like this at the end of a project! I could really use this feature for a pure model containing just CultureInfo and simple scaffolding of string inputs that convert easily.