1

Closed

Metadata API usability: it is not possible to publically create certain type usages

description

As part of the work on public code first conventions we are enabling user code to manipulate EF models at runtime. Unfortunately there are several fundamental pieces missing in the object model that represents the different layers of an EF model. In the design meeting of 1/17/2013 we decided we would consider making changes as part of pre-release API scrub/polish, adding new surface and obsoleting old surface where the value in doing so is significant.

Here is a particular issue that we might want to address: Public TypeUsage builder methods exist such as
  • CreateDefaultTypeUsage(EdmType edmType),
  • CreateStringTypeUsage(PrimitiveType primitiveType, bool isUnicode, bool isFixedLength, int maxLength)
  • CreateTimeTypeUsage(PrimitiveType primitiveType, byte? precision)
  • Etc.
There are basic combinations, like nullable int, that are missing and the basic building block, which would be more convenient to create TypeUsages programatically, Create(EdmType edmType, IEnumerable<Facet> facets), is internal.

As a consequence it is not possible to create some of the supported type usages using public API.

We should consider filling any holes in the builder methods and making any useful building blocks public, e.g. making Create(EdmType, IEnumerable<Facet>) public as well as making Facet publically constructible somehow.
Closed Dec 12, 2016 at 9:43 PM by RoMiller
EF Team Triage: We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base.

Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).

This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include:
  • It was a bug report that does not contain sufficient information for us to be able to reproduce it
  • It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it
  • It is a feature request that we are realistically not going to implement on the EF6.x code base
    Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). We will no longer be monitoring this issue tracker for comments, so please do not reply here.

comments

RoMiller wrote Feb 7, 2013 at 10:14 PM

EF Team Triage: This is small, we should push to get it into EF6 even though it's lower priority.

RoMiller wrote Dec 12, 2013 at 9:04 PM

EF Team Triage: Moving issues with Impact set to Low out of the 6.1.0 release as we only have time to address High and Medium issues in this release. We will re-triage these issues for future releases.

This does not exclude someone outside of the Microsoft EF team from contributing the change/fix in 6.1.0.