Design Meeting Notes - March 28, 2013

Rename of DbExtensions to IQueryableExtensions

DbExtensions was renamed to IQueryableExtensions in EF6. This is technically a break and discussion centered around the various merits of taking the breaking change vs. reverting the rename.

Decision: We like the convention of grouping and naming extension method classes after the type they target, so we will leave IQueryableExtensions as is, and also fix our only other inconsistency: DbSetExtensions, by renaming it to IDbSetExtensions.

Pattern for customizing migrations history table

Rowan discussed some learnings from his exploration of this feature. Notably that it doesn't support multiple providers because we store a single history context metadata snapshot in the code-behind. We primarily do this to both support history table move operations and enable error detection of invalid history context changes after the initial migration.

Decision 1: Remove the history table metadata from the code-behind. Mis-configuration errors will no longer be detected and often now come from the provider during Update-Database. In some cases, no error will be raised but a parallel database schema will be created (such as when DefaultSchema changes).

Decision 2: We need to support provider specific history context factories.

Turning off automatic transaction creation

Because of the introduction of execution strategies in EF6, we now create transactions for database operations where we wouldn't have in EF5. This is a problem for database operations that can't run inside a transaction, such as Use Federation.

We discussed various solutions to this, all essentially boiling down to ways of allowing the user to opt-out of automatic transaction creation.

Decision: This is mostly a problem when using ExecuteStoreQuery. We will add an overload of ExecuteStoreQuery which takes an enum specifying the desired transaction behavior. Values: "Default" - same as without the overload and "NoTransaction" - no transaction should be created.

Buffering in EntityClient and MARS from default connection factory

We've added result buffering by default in EF6 but this has not been enabled for EntityClient queries.

Decision: We won't enable it in EntityClient for EF6.

We changed the default connection factory in EF6 to turn-off MARS. This can break existing applications that are relying on MARS.

Decision: The benefit of disabling MARS from the default connection factory seems negligible and so we will re-enable it.

Last edited Mar 29, 2013 at 9:16 PM by AndrewPeters, version 7