Support for simple type mapping or mapped type conversions
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.
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.
RJ Hollberg commented
We really just need mapping in general, preferably using lambda expressions. The types that are usable by ORMs and DBs in general are simply much more limited than a smart domain model requires. We have custom Money and Currency types that we need to map to numeric fields; we have a custom EmailAddress type that we want to map to string fields; We have Doubles that Oracle returns as type Decimal and we need to cast them back. Booleans and Enums are also prevalent in our model, as are Nullable<T> types.
IPAddress as varbinary.
enum as string!
Brett Bailey commented
Really need to be able to store an enum as string
Jakob Jónasson commented
I have a legacy database and would like to map a small int column to a boolean value in my code first model.
It would be great to be able to add two lamdas to a Mapping to be able to convert from Model type to Db expected type and back again. I to also would like to convert enums to their string format in the database to and back to the enum in the model. I hate having an extra level of mental mapping when looking at data in tables especially if space is not a concern.
Ricardo Wickel commented
The most important for me is that enums can be stored as strings (varchar).
Volodymyr Bilyachat commented
@Damian Powell whats wrong with enums? right now you can use them.
Damian Powell commented
I work on a large, old, legacy database which uses a lot of enumeration values which are annoyingly mapped to different field types in different tables (i.e. smallint in some cases, int in others). This feature would help alleviate that problem for me. Currently I have to work around it in my entity. LINQ to SQL can handle it though!
Volodymyr Bilyachat commented
In NHibernate there is function
Map(x => x.Cache).Column("main_image_info_cache").CustomType<JsonField<PetCacheField>>();
So all what i must to its create custom Mapper JsonField and then it will be able save data as string to my database.
Rob Grainger commented
Too often, MS concentrate on green field development. The majority of their customers have to exist in the real world of brown-field development. Features like this really help bring existing applications into the real world.
I'd suggest MS try to get their developer's a couple of large scale "typical" legacy databases, and make any data layer features be applied to these, so they get some perspective on features the rest of us may need.
Code First sounds real nice, but is useless where existing data exists.
Rob Grainger commented
For working with legacy databases it is unbelievable you cannot map YN to Boolean. Failure to support this pollutes the entity layer with database-mapping concerns.
Paul Gwynn commented
I just couldn't begin to count how many 'groans' a feature like this would have saved me over the past few years building on top of legacy databases.
Graeme Miller commented
Be nice to be able to map .Net TimeSpan property directly to something in MS SQL server. CodeFirst seems to map Timespan to a SQL Timespan which is only 24 hours and you have to put a wrapper around it.
I'm defining my domain model and wanted to see if a property of type CultureInfo can be mapped to a varchar. I used NHibernate previously and this was a no-brainer. I hate adding properties just to make the O/R mapper happy. It ain't right.
Dan M commented
I definitely would like a feature like this for mapping enums fields stored as strings (varchars) to enums.
I've found this would be a useful feature when I attempted to use EF to map two similar but different data models to the same domain model. In several cases the columnar data types differed (e.g. varchar in one, integer in the other), and this can limit the possibility of mapping both models to the same POCO domain model
Marc Lewandowski commented
It isn't just "like" IUserType, I have seen the absence of this feature used as a selling point in steering folks away from EF and toward NH. It is definitely a missing feature. @Ladislav, thanks for your advocacy on this, you've been ringing this bell for a while! Hopefully this is gaining some traction at MS.
In NHibernate it's IUserType - it's a simple mapper between your database type and the entity type.
It's mostly used for images and Xml.
It would be an easy way to support enums before we get it in EF 5 :)
This is a hugely important feature that I have been fighting a LOT lately. In particular the ability to store complex object states (e.g. JSON) in database columns would be great.