Support for custom type mapping and data store to CLR type conversions

There is a continuum of scenarios that can be supported here:

• Allow for simple hard coded conversions between types that are related in a well-know manner to types that are supported. E.g.:
  • char can map to the database exactly as a string of size 1 (see #8656)
  • byte can map to the database exactly the same as a byte[]
  • signed or unsigned small integers can fit in the nearest wider signed or unsigned integer
• Allow providers to supply their own additional type mappings for types they don’t support, e.g. if a database engine doesn’t have native support for bool, it can decide to use a small integer representation
• Allow specific well known scenarios that are commonly demanded, like mapping enum types to strings
• Allow for conversions to be performed on the server (vs. only on the client) for cases in which there isn’t a viable CLR representation for the server type - see #10434 and #10861
• Allow for user provided conversions

They all probably require extending the reach of the type mapper to be able to participate of the generation of:

• Parameters
• Expressions for value access in materialization
• Expressions for equality and inequality comparisons - see #10265
  1. Equality on the server should be equivalent to equality on the client as long as the conversion is deterministic and bijective.
• Order comparisons and sorting - see #10265
  1. Comparisons and sorting are equivalent as long as the conversion is a monotonic function (although reversed if it is decreasing)
  2. For non order-preserving conversions, we may need to differentiate the scenarios in which we introduce sorting just to get the order of two or more results to be deterministic so we can zip them together, vs. explicit ordering requested by user, which we may need to evaluate on the client after the conversion is performed.
• Operator and function translation - see #10434

[netcore-jroger]

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

[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. https://github.com/Azure/azure-storage-net/issues/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.