Add support for Half in EF Core
Opened this issue · 14 comments
Need to create full half type support for ef core.
- Value converters,
- Compiled models,
- Migrations,
- Mapping
@bricelam Hi, could we discuss how to create full supporting half type for ef core? May be all familiar to float or decimal type?
@newmasterSG regardless of the support, I'm curious about why you need half support in Sqlite (or EF in general) - could you provide a bit of context/background on your scenario here?
@newmasterSG so you don't have any concrete need yourself for Half support in EF, right? No database that I know of supports Half - that type is useful mainly for faster, lower-accuracy floating point calculations, which are generally less relevant in relational databases (a vector of Halfs might make more sense, but that's not what this is about).
@roji Hm, that's make more sense, thank you for your explanation, so maybe that's better to close this issue, however I didn't fully understand, why team said that need to create separate issue for whole ef
@newmasterSG note that I'm not saying we shouldn't merge the PR (or close this issue) - just trying to understand what the actual real-world usages would be of using Half in SQLite.
To quote some random person on the internet:
Computations in machine learning take advantage of the decreased precision to speed up calculations and cut down on storage space. So, this would probably be the primary use case for a Half.
@bricelam that's true, but AFAIK that's generally works well in vectorial/columnar contexts, where an operation is performed over series of Halfs. I'm not sure how having a Half column in a relational database - which is row-based - actually helps someone in a concrete context; but I could be wrong - that's exactly why I'm trying to hear from someone who actually wants/needs this, rather than submitting a PR just to do it for others.
Just to clarify for myself... Do we discuss here Half in EF Core or in Microsoft.Data.Sqlite? The issue title says EF Core, but reading in between the lines it looks like we're also talking about Microsoft.Data.Sqlite.
To reiterate current team's status:
- We're happy to take contribution of adding
HalfintoMicrosoft.Data.Sqlite(#30931). Majority believe (and yes, we had to massage @roji a bit ;)) that it falls into same category asshort,float, orTimeOnly. You can go ahead with it @newmasterSG. - Adding it into EF Core needs more understanding on our side why to do it "in the box". Instead of i.e. utilizing value converter (given that virtually no database at the moment supports such datatype). Basically what the scenario is and how we can help making it more awesome by supporting
Halfthere.
@cincuranet just noting that if/when we add support to M.D.Sqlite, it makes sense to add Half support to the Sqlite EF provider as well - without needing any value converter (EF providers generally expose all types supported by the underlying ADO.NET provider). For other database, since there's no ADO.NET provider support, the only thing we can do is to add a value converter, which I don't think we should.
To play devil’s advocate, what was the point of adding a Uri and IPAddress converter?
To play devil’s advocate, what was the point of adding a Uri and IPAddress converter?
That was my fault. Shay uses these as an example of where we did it wrong. 😆
Then I believe Shay and I are in agreement. This becomes a provider-specific feature of M.D.SQLite (and its EF provider) and just for the sake of completeness.
To play devil’s advocate, what was the point of adding a Uri and IPAddress converter?
That was my fault. Shay uses these as an example of where we did it wrong. 😆
Just to be extra clear, I think adding EF-level value converters for arbitrary types (like IPAddress) is (much) more reasonable than adding ADO.NET support (when the type isn't natively supported) - EF is a much higher-level thing and goes way beyond "just exposing the database" (which ADO.NET is quite close to). That's also why I don't love the idea of adding Half support to M.D.Sqlite (it's not a standard, universally supported type like DateTime or decimal).
Even for EF I'd prefer for users to just specify value converters explicitly - especially where the conversion is as trivial as in this case - rather than EF doing magic which hides what's actually going on from the user. I wouldn't go so far as to say "we did it wrong" - it's just not my preference :)