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.
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?
- Remove Edm and Db prefixes
- Change namespace to S.D.E.Model
- .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?
The following code will no longer compile.
PrimitivePropertyConfiguration property = modelBuilder.Entity<MyEntity>().Property(e => e.MyProperty);
This is because PrimitivePropertyConfiguration is now generic.