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).
- 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).