Hey guys, I have a scenario where I am writing code-first POCO entities to represent an existing DB of which I have no control over the schema. Each table has an integer-based primary key which is either an "int" or a "bigint".
I want my entities to derive from a common base class that implements an interface, IEntity, defining a singular EntityId property in order that the rest of my code (making use of Repository and Specification patterns) can be as simple as possible (avoiding the need for Int64/Int32 checking etc). I have defined this as an Int64 type in the interface and base class.
I have found that EF does not like this. It will throw an error if you try and read an Int32 value from a DB into an Int64 property in your POCO entity classes. I can understand how this would be a problem the other way around but in my scenario I don't see why this should be an issue.
I had two choices to fix this, I either refactored all of my interfaces, specification, entity base and repository framework classes to specifically handle the two different scenarios of 64 and 32 bit ints OR I tweaked the EF code to relax it's checking / tweak it's handling of integer types to allow the writing of 32 bit DB values into 64 bit ints.
I tried the latter option and found I only had to make minor changes in 4 classes to make this work (tweaking the BufferedDataRecord to cast if necessary and tweaking some equivalence checking to allow equal value integers across different data lengths (32, 64) to be considered equal).
I was just wondering if there was a reason that EF disallowed this and if my tweaks could cause me any problems down the line? Would there be a possibility in the future that we could have an option to relax this kind of data-checking so in scenarios such as mine that this could become an implicit part of the framework?
Cheers for any feedback,
James.
I want my entities to derive from a common base class that implements an interface, IEntity, defining a singular EntityId property in order that the rest of my code (making use of Repository and Specification patterns) can be as simple as possible (avoiding the need for Int64/Int32 checking etc). I have defined this as an Int64 type in the interface and base class.
I have found that EF does not like this. It will throw an error if you try and read an Int32 value from a DB into an Int64 property in your POCO entity classes. I can understand how this would be a problem the other way around but in my scenario I don't see why this should be an issue.
I had two choices to fix this, I either refactored all of my interfaces, specification, entity base and repository framework classes to specifically handle the two different scenarios of 64 and 32 bit ints OR I tweaked the EF code to relax it's checking / tweak it's handling of integer types to allow the writing of 32 bit DB values into 64 bit ints.
I tried the latter option and found I only had to make minor changes in 4 classes to make this work (tweaking the BufferedDataRecord to cast if necessary and tweaking some equivalence checking to allow equal value integers across different data lengths (32, 64) to be considered equal).
I was just wondering if there was a reason that EF disallowed this and if my tweaks could cause me any problems down the line? Would there be a possibility in the future that we could have an option to relax this kind of data-checking so in scenarios such as mine that this could become an implicit part of the framework?
Cheers for any feedback,
James.