Entity Framework Feature Suggestions

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 ...

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.

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.

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.

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.

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.

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.

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.

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.

A truly useful feature would be the ability to define lambda expressions for property-level conversions in the EF context configuration, which would help address the enums-as-strings problem and a bunch of others.