Support for custom type mapping and simple data store to CLR type conversions #242

Open
rowanmiller opened this Issue May 22, 2014 · 26 comments

Projects

None yet
@rowanmiller
Member

No description provided.

@rowanmiller rowanmiller added this to the 1.0.0 milestone May 22, 2014
@mj1856
mj1856 commented Nov 7, 2014

Just checking - Is this the work item tracking this uservoice item? Thanks.

@rowanmiller rowanmiller modified the milestone: Backlog, 7.0.0 Dec 1, 2014
@mj1856
mj1856 commented Jul 12, 2015

Any movement on this? Or hint of direction, proposed API, anything? Thanks.

@rowanmiller
Member

@mj1856 nothing yet. We know we want to do this (and that has influenced how things are architected internally) but we're currently planning to work on lighting this feature up after our initial RTM of EF7.

@mj1856
mj1856 commented Jul 15, 2015

Thanks!

@smitpatel
Contributor

Details:
At present we are making changes to our property discovery so that all the types supported by the provider can be mapped as primitive properties. In the addition to provider supported types, user may want to use some other type as a primitive by providing a custom typemapping through which it can be mapped to one of the known types of the provider and subsequently be used as a primitive property.
Also see #2588

@smitpatel smitpatel changed the title from Flexible data store type to CLR type conversions to Add support for custom typemapping for data store type to CLR type conversions Sep 4, 2015
@divega divega changed the title from Add support for custom typemapping for data store type to CLR type conversions to Add support for custom typemapping for data store type to CLR type conversions (aka custom TypeMapping) Sep 4, 2015
@divega divega changed the title from Add support for custom typemapping for data store type to CLR type conversions (aka custom TypeMapping) to Add support for custom typemapping for data store type to CLR type conversions Sep 4, 2015
@divega divega changed the title from Add support for custom typemapping for data store type to CLR type conversions to Add support for custom type mapping for data store to CLR type conversions Oct 1, 2015
@ilmax
ilmax commented Oct 8, 2015

Does this allow me to map a custom type to whatever filed in the storage? e.g. create a custom type for entity.Id (which only wraps an int) instead of using int or map enum to char?

@mj1856 mj1856 referenced this issue in dotnet/corefxlab Oct 9, 2015
Open

At/On overloads that return DateTimeOffset? #300

@Rseding91

This is exactly what I was recently looking to do. It would be an extremely useful to have this.

@Marusyk
Marusyk commented Nov 21, 2015

I need the same possibility as mentioned by @ilmax:

Does this allow me to map a custom type to whatever filed in the storage? e.g. create a custom type
for entity.Id (which only wraps an int) instead of using int or map enum to char?

Does this allow me to do that?

@mojtabakaviani

Please provides interfaces can add to model binder or use as attributes for converting any types.
for example convert string to xml or json object, custom calendar datetime or any class or struct and inverse any types to string for save to database, so can map saved data to any database types.

@mj1856
mj1856 commented Jan 8, 2016

@rowanmiller - it would be really helpful if you could please give us a status update or at least the general design plan for this feature. Thanks.

@rowanmiller
Member

@mj1856 this will definitely be a post-7.0.0 feature. We haven't done any planning/prioritization of work items for post-7.0.0 yet. We'll be doing it around the time of the 7.0.0 release and will share plans as soon as we have them.

@mj1856
mj1856 commented Jan 11, 2016

Thanks.

@netcore-jroger

do you have any plan to implement this feature/api ?

@rowanmiller
Member

No exact plans of release etc. It is lower priority that some other features, but we may end up implementing it as part of one of the higher priority features as it may help with the implementation.

@ajcvickers ajcvickers self-assigned this Jul 8, 2016
@Misiu
Misiu commented Aug 9, 2016

This is third highest ranked feature request on uservoice
I was looking for such ability in EF 6.1.3, but without luck. Having this build-in would be very useful.
Version 1.0.0 is already released, maybe now this can be implemented. @rowanmiller any news?

@divega divega changed the title from Add support for custom type mapping for data store to CLR type conversions to Support for custom type mapping and simple data store to CLR type conversions Aug 9, 2016
@divega
Member
divega commented Aug 9, 2016

@Misiu this is one of three features we will start working on soon although they are not really planned to ship as part of EF Core 1.1. See https://blogs.msdn.microsoft.com/dotnet/2016/07/29/entity-framework-core-1-1-plans/ for more details on 1.1 priorities.

@Misiu
Misiu commented Aug 9, 2016

@divega thanks for link. Hopefully everything will go well and simple type conversions will be included ๐Ÿ˜„

@dirq
dirq commented Aug 10, 2016

Enum to a db lookup table please!

@mj1856
mj1856 commented Aug 10, 2016

As a proof of concept, please consider a project that uses an entity such as:

public class Person
{
    public int Id {get; set;}
    public string Name {get; set;}
    public Date BirthDate {get; set;}
}

In this case, the BirthDate property is a System.Date struct, found in the System.Time nuget package from corefxlab.

The entity should be able to participate in all EF normal CRUD operations, including querying with the field in a filter, sort, or projection. The backing store for the field should be a SQL date type.

The developer should be able to somehow write a fluent mapping or class with to/from methods that control how the custom data type hooks in to EF. They should not have to think about it on a per-operation basis.

@ajcvickers ajcvickers removed their assignment Oct 6, 2016
@rowanmiller rowanmiller referenced this issue in aspnet/EntityFramework6 Oct 12, 2016
Closed

Ability to coerce value of a property of an entity #62

@AlanParr

Just to provide another use case for this. In our system we have batch numbers, these are a string but that string has a great deal of meaning so we would like to encapsulate it to prevent unauthorised adaptation and isolate logical operations that are performed on it. If we had a class like:

public class BatchNumber{
   public bool IsReturn();
   public bool IsDispense();
   ...
}

We would be looking for some way to map the VARCHAR database field to this class in the model.

Not sure how this would work from EF's perspective, constructing the object would be easy enough as the author could provide a parameterized constructor, not sure how you'd get the content back out again though as this would obviously not serialize well, a public getter probably wouldn't be desirable either as the purpose of the above is to encapsulate the value, an intention that would be defeated by making the internal value accessible.

I suspect @mj1856 suggestion of fluent mapping with defined to/from methods would be the simplest and most flexible solution.

@divega
Member
divega commented Nov 24, 2016 edited

See the issue about custom property access patterns (#2968) for a pattern we could possibly enable to specifying two-way type conversions as well.

@chadwackerman

@rowanmiller I'm escalating this because you may not be aware of how broken things are.

I ported a braindead simple app to .NET Core. Because I'm over the age of 25, I originally declared one of my database fields as unsigned long. Resulting in this error using the new stack:

The property 'Size' is of type 'ulong' which is not supported by current database provider.

This leads me down an absurd path of broken workarounds and public evidence that Microsoft can't get out of its own way. Microsoft's standard technology for writing numbers into SQL Server regressed this basic functionality?

Just spitballing here, but I can't imagine enterprises are going to modify their schema (especially something as tweaky as unsigned) just because two Microsoft program managers haven't been able to sort this out after 30 months of meetings.

The native SQL Service provider was retired in 2012 for whatever reason. Now you're using the generic provider and it doesn't support unsigned. So here I am five years later watching this unfold in slow motion on GitHub.

I'd use friendlier tone but frankly I've run into over a dozen simple issues where it's clear that nobody is testing basic functionality of anything with these new libraries. It's a bunch of Microsoft silos assuming everything will just magically work together when I type in a code snippet from a MSDN article that has a publication date of one week ago yet refers to an outdated library. Then after making whatever idiotic and unnecessary name tweaks I find on StackOverflow, Visual Studio magically plucks a library from NuGet.

Apparently there's someone sitting in a corner office thinking this works. I am hereby sounding the alarm that it does not.

Also I'd love to chat with the people responsible for 1) killing the SQL client 2) ignoring the missing functionality for five years in ADO or whatever you're calling data providers this week and 3) sitting on this very issue for 30 months despite it being at the top of the UserVoice site.

Also the EF 5 -> 6 -> Core -> 7 transition. Seriously? There's lots of open source code calling this stuff. Did you do any analysis of what features were actually in use before you started killing and renaming things or did you just tape the specs to the wall and throw darts at them?

I might suggest you use Azure Batch service and run some data analysis to prioritize features since you're ignoring UserVoice. You could start by putting some GitHub projects into Azure Blob storage. However neither Azure Batch or Azure Storage libraries run on .NET Core because they're pointing fingers at each other over dependency problems. And yes, for some reason Blob Storage pulls in some of these inane types discussed here because the storage team can't bear the thought of having Table Storage in a different DLL. Azure/azure-storage-net#97

So congrats, you're blocking a $10 billion business because you can't figure out how to support dates or unsigned types properly. Let alone "spatial" or (gasp) "xml".

The situation is frankly embarrassing and having these unaddressed issues sit in the open for years doesn't buy you much goodwill either. All of this stuff is far too complex for "the community" to help with. You gotta break things up into sane pieces and be more clear with future plans if you want to leverage goodwill here instead of just pissing people off.

@TsengSR
TsengSR commented Dec 13, 2016

@chadwackerman: Maybe read the road map twice and in general blog and posts related to EFCore before "blocking" yourself/your business critical applications:

https://github.com/aspnet/EntityFramework/wiki/Roadmap

Critical O/RM features

The things we think we need before we say EF Core is the recommended version of EF. Until we implement these features EF Core will be a valid option for many applications, especially on platforms such as UWP and .NET Core where EF6.x does not work, but for many applications the lack of these features will make EF6.x a better option.

Before making yourself an idiot? Or just RTFM:

Because of the fundamental changes in EF Core we do not recommend attempting to move an EF6.x application to EF Core unless you have a compelling reason to make the change. You should view the move from EF6.x to EF Core as a port rather than an upgrade.

@chadwackerman
chadwackerman commented Dec 13, 2016 edited

Believe me, I'm all too aware of the state of the various database technologies, Http libraries, and incompatible .NET frameworks. I do not think people like @rowanmiller are.

I ported my data layer to EF Core in twenty minutes. Read the readme, worked around the issues, got 'er done. Was lucky enough that I could change my schema to work around Microsoft's abandonment of the top bit in SQL Server. (But hey... SqLite and Redis work with unsigned so Scott Hanselman can keep rocking his fraudulent tradeshow demos claiming all this stuff works.)

Meanwhile back on planet Earth where people actually build things, we've got a bug going back to 2014 that's holding up at least six product groups at Microsoft. Y'all are welcome to play ping pong on Github and continue clicking the upvote button on UserVoice but it doesn't seem to be moving things forward.

Edit to add: one of the reasons behind my being forced to move to .NET core was the fact that there are numerous broken dependencies on .NET 461 now causing all sorts of issues. Including silently breaking https calls at runtime (no compiler warnings) unless you manually tweak your bindings, which get overwritten every time you touch NuGet: dotnet/corefx#11100. This was an attempt (successful!) to unblock myself from an even more critical issue, for which Microsoft doesn't even have a timeline.

EntityFramework isn't someone's hobby project, fellas. I'm paying big bucks to run stuff on Azure. I'm not gently asking some hobbyist to add a pet feature to yet another stupid blog engine. I'm demanding that Microsoft fix priority 1 bugs that block critical functionality, not sit on them for months/years with no community updates.

@jtheisen

@chadwackerman I didn't think anyone in the money making business would touch anything with the word core in it yet.

@chadwackerman

Right. Because the dependencies are a disaster. Because there are 30 month old bugs like this one preventing Azure Storage and Azure Batch from shipping their libraries. Thus me taking the time to write up the issue.

Microsoft's shipped 1.0 and 1.1 versions of DotNet Core, ASP.NET Core and EF Core. As part of the November 1.1 releases they managed to screw up the .NET 4.6.1 dependencies. I was given a choice of going back to 4.5.2 (not feasible) or biting the bullet and moving to Core 1.1.

It all works (believe it or not) however the problem is lingering libraries because we've got people sitting on bugs like this one. Meanwhile the insane Storage team insists on shipping one huge library instead of a simple REST client: picking up OData, Spatial, Data Modeling, WCF and KeyVault dependencies along the way.

Meanwhile everything at Amazon just works in C#. I cannot believe I can use .NET Core to manage AWS Elastic Beanstalk (whatever the hell that is) but I can't use it to upload a blob to Azure. Because of an ADO provider glitch from 2012.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment