Design Meeting Notes - October 4, 2012
Global spatial provider
The initial spatial support in EF5 added support for spatial types backed by provider-specific native spatial libraries. This should work in most cases with providers other than SQL Server. However, creating stand-alone DbGeography and DbGeometry types for
other providers was not possible because there was no way to register the other provider with EF. This has been fixed in EF6 by allowing the registration of a global spatial provider. However, this is not an ideal solution because it means that only one spatial
provider can be used in app domain. A better solution would be to change the design of DbGeography and DbGeometry to decouple them from the native provider except when necessary, and when it is necessary to this in a way that the provider to use is explicit.
It would also be worth considering using the System.Spatial library and deprecating DbGeography and DbGeometry.
- Updating the spatial work is not high enough priority for us to work on now but we will create a work item for it.
- We will retain the global provider, and also check in the ability to set the global provider in the config.
There are not very many, if any, parts of the API for single types where there is no scenario for a set based application. So our initial plan will be to assume that we are implementing all, or at least the majority, of the current Fluent API but with a
set based approach to apply configuration to a group of entities, complex types or properties.
The table below shows side by side syntax for configuring some common scenarios, one doing it to a single thing the other to a set. The syntax is based on some of the feedback and discussions from last week; you would be able to pass a lambda into the Entities
and ComplexTypes methods to filter the types you are applying it to.
|Set decimal property precision on entity
.Property(x => x.DecimalProperty)
|Set Key of entity
.HasKey(x => x.BlogKey);
|Configure property on complex type
.Property(x => x.DecimalProperty)
Given this approach if I want to define all decimal types have a specified precision, regardless of if they are a complex type or entity, and then I need to define it twice. Which is not as DRY as it could be.
- Do nothing, and tell people to write a property convention if they really want to do it in a single place. This still scatters code a little bit, as the convention will be in a different location to the rest of the code.
- Define a third root to use for when you are configuring both entities and complex types. This would look something like this:
//Types is not a really good name, but it will do for now.
- Implement a method similar to Linq Concat. This could look something like this:
- Have a top-level Properties method
Decisions/ideas from the meeting:
- The vast majority of complex types are used as properties on entities. This means that when you configure something like precision for all properties of an entity you are also configuring for all properties of the complex type on that entity, and on child
complex types of the complex type, and so on. This means we probably only need to have Entities at the top level—we’ll start with this.
- A good name to use with the nested closure is “Configure” with configuration object and property passed in.
- We’ll create an initial one-pager for this work and post to CodePlex