This project is read-only.


Review Metadata APIs made public for EF Designer


Review Metadata APIs made public for EF Designer:
  • is the set complete (i.e. aren't we missing accepting some parameters only because they are not used by the designer, aren't we missing types that are not used by the designer)
  • do we need to hide or refactor some code made public (especially EdmFunctionPayload where some of the exposed properties don't seem to be useful for external users at all)
  • for newly added factory method - are all the paremeters sufficiently verified? Do we have asserts that now should be turned into exceptions (already found 2 like this - e.g. creating a function with an input parameter whose mode was ParameterMode.ReturnValue)
  • EntityType and ComplexType can now be created without properties or key members (designer may take advantage of this) - throw? validate?
  • For mapping API - are all classes and properties required to reason about mapping open? Should we do some exploratory testing for this?
  • For mapping API - some ctors may take parameters that are later not exposed - we probably should create ctors that don't take such parameters or if not possible expose properties accordingly
  • For mapping API in some cases we may now throw a NotSupportedException (vide FunctionImportMappingComposable) from a ctor. The exception says you cannot create something which actually can be (and is) created internally. The reason for this is that the designer does not need it and the mapping API should be mainly for reading the mapping. Is throwing the exception (an alternative is to accept more parameters in ctors and do more throughout parameter verification).
  • Review FxCop suppressions added to mapping APIs (especially around type of structuralTypeMappings in FunctionImportMappingComposable and FunctionImportMappingNonComposable)
  • Check whether StorageAssociationSetModificationFunctionMapping needs to be made public, as well as the getter for StorageAssociationSetMapping.ModificationFunction.
  • StorageEndPropertyMapping derives from StoragePropertyMapping but it does not seem to be needed. Can we/Should we remove the base class?
Closed Jul 23, 2013 at 8:45 PM by ajcvickers
Closing this as verified because we went through the metadata APIs as part of the core classes API review.


emilcicos wrote Jul 15, 2013 at 9:29 PM

Mapping API are now internal. Fixed a few issues with Create factory methods. EdmFunctionPayload remains the same.