Design Meeting Notes - September 20, 2012

By-convention parameter binding SqlQuery overload

This is a proposed contribution by hintzen to add overloads of SqlQuery that accept a single object argument representing the set of parameter values. Binding would happen by convention based on the property names of the provided parameter object.

Decision: We would consider this contribution.
Feedback: The new methods should be overloads of SqlQuery/ExecuteSqlCommand.

SqlCE relative path connection string UX issues with Migrations

Issue: Relative path connection strings in CE resolve to the VS installation folder when running migrations inside VS.
Decision: Considering auto-prepending "|DataDirectory|" as a mitigation. Brice investigating implications for different scenarios.

Pluggable Conventions

Polish the model representation

Should DbModel inherit from DbDatabaseMapping?

• Initial concerns were around its mutability after calling Compile()
• Leave it as is (a property on DbModel)

How much should we align with OData’s EdmLib?

• Not worth adopting code
  • Cost of implementing SSDL & MSL
  • Freedom to evolve our API independently
• Look at aligning names of types and properties where appropriate

Should we avoid calling it “EDM” and adopt a more EF-specific taxonomy?

• Yes
  • Remove Edm and Db prefixes
    • Rename any conflicts
  • Change namespace to S.D.E.Model
    • .Database
    • .Mapping (directly under Model)

Should we address the duplication of concepts/code from System.Data.Entity.Core.Metadata?

• Original idea was that this would replace the old stuff
  • We will probably never get around to doing this work

Need to address public setters on collection properties.

Polish the conventions API

Should we allow greater control over the order of conventions?

• Is there a way to avoid calling ApplyPluralizingTableNameConvention from inside DbModelBuilder.Build?
• Need a way to determine the order of default conventions (Documentation)
  • Is there a better way to group things? (e.g. keys before foreign keys)
• Add AddBefore method
• Could add conventions immediately after their derived type

Should any of our conventions be sealed? …not publically constructible?

• No, keep open unless there is a compelling reason not to

Make it easy to override parts of the default conventions (similar to customizing our migrations provider).

The ConfigurationBase hierarchy needs to be simplified. Currently, there is one set that gets returned from the Fluent API and another that you use for writing conventions.

• Like this because you don't have static types. Similar to having generic and non-generic APIs

CTP5 post mentions “It does not allow you to read information about the shape of your model.” Has this been fixed by making Edm public?

• Fixed. Ensure there is a way to get to root EDM model from conventions

Are we correctly using Type vs. TypeInfo? (See Evolving the Reflection API)

• Need to support net40
  • Did TypeInfo exist before net45?

Is there a way to fail during Add() if an IConfiguration will never get applied?

• Find out specific combinations that don't work
• May not be able to do anything aside from documentation

CTP5 post mentioned changing the IConfigurationConvention.Apply parameter to not be a Func<tconfiguration>.

• Like this for lazy creation
• Could have a wrapper
• Could detect if configuration changed after Apply and throw it away if not

How does this work integrate with the dependency injection work?

Breaking change

The following code will no longer compile.

PrimitivePropertyConfiguration property = modelBuilder.Entity<MyEntity>().Property(e => e.MyProperty);

This is because PrimitivePropertyConfiguration is now generic.