This project is read-only.

Design Meeting Notes - January 17, 2013

Metadata API surface

Some parts of the metadata API surface obtained from the MetadataWorkspace and now used when creating model-based Code First conventions are hard to use and not well documented. Examples include:

  • EntityType vs EntitySet vs EntityState  - the XML documentation for these is self-referential
  • EdmMember vs EdmModel vs EdmNamespace vs EdmProperty  - the XML documentation for these is self-referential

Additional issues:

  • Hitting F1 does not take the user to MSDN documentation – CodePlex Issue 789
  • Exception messages are written from the perspective of the person implementing the EF code rather than being something understandable and actionable by the app developer
    • Example: The item with identity '`' already exists in the metadata collection


  • The documentation can be fixed for EF6, assuming it fits into the schedule – CodePlex Issue 788
  • Changing the actual API surface is harder since this surface is already public so any change will be a breaking change
    • We will consider changes as part of pre-release API scrub/polish and will consider adding new surface and obsoleting old surface where the value in doing so is greatest
  • We will try to make exception messages better as we hit them during development/testing

Pluralization service exploratory testing feedback

  • We should consider updating DbConfiguration documentation about Pluralization service
  • No functional tests yet
    • Should we add some, or ask the contributor to add some?
    • Given that is is not easy to functionally test (as opposed to unit test) the service we should do that—CodePlex Issue 790
  • Pluralize() method is called twice for each entity name
    • English pluralization service is idempotent, but interface does not imply that the service should be idempotent
      • There are methods IsPlural and IsSingular() in the interface, but they are not called before calling Pluralize/Singularize
        • Note that Singularize is not currently called at all, but the designer will use this
      • The implementation of the English service uses these methods
      • Decision: Remove IsPlural and IsSingular to make the interface implicitly idempotent and document as such—CodePlex Issue 791
  • HistoryRow and LegacyHistoryRow tables also pass through pluralization code.
    • This should not cause any harm
  • Is it necessary for the interface to provide some human-readable description that can be displayed in, for example, the designer?
    • Instead of doing this we will check for and use System.ComponentModel.DescriptionAttribute and fall back to using the class name

Metadata unification

  • OperationAction.Restrict is not supported by the EF stack—can it be deleted?
    • The meaning appears to be that a delete should be prevented if a child exists—somewhat the opposite of a cascade delete
    • If we cannot load a CSDL that contains this, then we should delete it
    • If we can load the CSDL, then we should ping Data Services to see if they use it at all, and if not then still delete it
    • CodePlex Issue 792
  • Boolean properties do not use the “Is” prefix
    • For example EdmType.Abstract instead of IsAbstract
    • We will consider in API scrub/polish and possibly create “Is” properties and obsolete old properties
  • Can extension methods originally added for Code First now be made first class?
  • Should the default schema now be implemented as a convention?
  • The unification means that the same types (e.g. EntityType) are now used for both c-space and s-space where previously different types were used. This means that the conventions are now using marker interfaces. Should we change the design here?
    • This is related other work to clean/update the design for conventions and should be considered as part of this issue—CodePlex Issue 795
  • MSL API is not currently public and doesn’t support going read-only
    • We will not make the MSL API public as part of EF6, but do plan to do this in the future—CodePlex Issue 646
  • Data Services annotations that were previously hard-coded into the model are not now included
    • Should these show up in core metadata?
    • Do they need to be serialized by EdmxWriter?
    • Follow up with Data Service team—CodePlex Issue 796
  • Validation exception types have changed from MetadataException to ModelValidationException when performing store validation
    • This is because SSDL validation is now being done in a different way
    • These are exceptions that are not reasonably recoverable from, so it is probably okay to change the type

Porting existing SQL tests

We want to continue to port old tests to the open source codebase. However, the old tests are problematic in that:

  • They use EDMX-based models
    • We should try using Code First models where possible
  • They run end-to-end from eSQL input to checking the results of running the query
    • This has the potential to create large baselines which are hard to  maintain/update going forward
    • We should investigate reducing the scope to test using asserts against only the query tree
    • We could also use the baselines are the basis for asserting against query results

How should pluralizers be made available?

Should we accept pull requests for pluralizers in our codebase?

  • We may accept such requests in the future, but for now we should be very careful, especially given the potential policheck issues with foreign languages
  • We should make it easy to create NuGet packages that automatically register a new pluralization service—see CodePlex Issue 765

Last edited Jan 18, 2013 at 9:43 PM by ajcvickers, version 3