Hi zgabi,
We have spent some time on the EF team brainstorming what we think the best approach is for tackling hierarchy ID and other related features. The conclusions from these discussions are as follows:
- It is currently hard for EF to support new data types because the Entity Data Model (EDM) needs to be updated to support each new type. There are times when adding types as first-class members of EDM adds enough value that it is worth doing all the work and reving the EDM version. However, there are also cases where the value of this is not high, and we believe that HierarchyID is probably one of these cases. In such cases we really want to make it easy to support new types without the EF internals having hard-coded information about those types. Instead we would need some form of extension points that can handle reading and converting from a data reader and also converting appropriately for updates. There probably also needs to be a way for the store model to handle the new type so that areas like Migrations can handle scaffolding for them.
- The dependency we took on the SQL Types assembly for spatial is problematic in several ways—for example, different versions of the assembly, needing to download and install the assembly on the client machine even when the rest of EF is bin deployable, the dynamic binding, and so on. It may be that we need to use the SQL Types assembly for HierarchyID but it is not clear that this is the case.
- It’s not clear what the most useful mappings are for hierarchy ID. Having a type like the one you added may be an approach we take, but it couples the application’s model assembly to EF, which is usually something we avoid. (I know that the spatial types do this as well, but this is a compromise we wish we could have avoided.) In line with the first bullet point, it would be good if the type we map to is not fixed. It may also be useful to map things like navigation properties over the hierarchical data, and in such cases maybe the HierarchyID itself can just be stored as a string property. We don’t necessarily need all of this to be done in a contribution, but whatever mapping we do choose should be flexible enough to handle such things in the future.
- The schedule and work we have planned for EF6 doesn’t allow us the time to go deeply into the design for everything above. However, we do plan to return to it after EF6 is released. At that time we would like to re-engage with you if you are still interested and potentially take some of your code or any additional work you do in this area as a contribution.
In summary, we appreciate greatly the work you have done here and your desire to contribute to EF, but for now we’re going to hold off on the contribution until we have a bit more time to ensure that we’re creating the best underlying building blocks for this area.
Thanks,
Arthur