Commits on Aug 15, 2013
  1. Merge pull request #2 from bricelam/master

    Update to 6.0.0-beta1
    marek-safar committed Aug 15, 2013
Commits on May 16, 2013
Commits on May 10, 2013
  1. Revert "Updating NuGet install logic to also remove System.Data.Entit…

    …y references from web site projects"
    This reverts commit c0da429.
    bricelam committed May 10, 2013
Commits on May 1, 2013
  1. DidIReallyDoThat (Fixing net40 test failures due to async operations …

    …not being run in net40 tests)
    ajcvickers committed May 1, 2013
  2. LexLutherStrikesBack (Fix additional bug around decimal scale/precision)

    In the previous fix the Scale was not being set put Precision was still being set. It turns out that in this combination if the total number of digits in the decimal is greater than the set precision, then SQL Client throws. The fix is to set neither, in which case the decimal value is passed through unchanged.
    ajcvickers committed May 1, 2013
Commits on Apr 30, 2013
  1. EveryStepYouTake... (Building blocks for interception)

    These changes build on the work previously done to add the building blocks for interception and provide concrete implementations of these for DbCommand execution interception.  The basic parts are:
     - A set of interfaces that provide the interception methods for types/operations that can be intercepted. Currently public interfaces are provided for command execution and command tree creation, and there are also two internal interfaces used by Code First/Migrations.
     - A mechanism for registering objects that implement one or more interception interfaces.
     - A mechanism for dispatching notifications to the registered interfaces. This mechanism is public so that external code (such as providers) can dispatch notifications when doing things on behalf of EF. Currently only dispatching for command execution is public.
     - The mechanism for registering/dispatching is intended to be optimized for fast dispatch rather than fast registration. Also, registering an interceptor for one interface does not slow down execution/dispatch around other interfaces.
     - A mechanism to provide contextual information about the operation to the interceptors. Currently this contextual information contains the ObjectContext/DbContexts that cause the operation to happen (when available) but in the future we can include other information here--for example, we may include the public surface method (e.g. SaveChanges) that triggered the operation.
    - Interceptors can be flexible in how the callback methods are defined. Currently the command execution interceptor interface has methods for before and after execution with the result of the execution supplied to the “after” methods. The “after” methods can also modify the result before returning it. There is an internal command dispatcher that allows cancellations, but the publicly exposed version does not since cancellation needs to be handled properly at all call sites.
    Open questions/remaining work includes:
     - We should define a nice sugar API on the context for logging SQL. We need to decide what this looks like, what it supports, and what the consequences are for trace strings and parameters.
     - Interceptors could be defined for many more things. We should decide which others (if any) we want to do and have time to do for EF6. For example, DbProviderServices, DbConnection, other DbCommand operations, transactions, etc.
     - Is the granularity of the interception methods correct, especially for command interception? For example, should we collapse the sync and async methods? (This has consequences for handling results.)
     - What should happen if the operation that is being intercepted throws? Should the “after” method be called? (Currently it isn’t.) If it should be called, should it contain exception information?
     - These are very low level interceptions. We currently call them the way we do. In the future we may change internal code so that we call them differently. Should we be concerned about the potential for breaking changes here?
     - The command tree interception context contains the ObejctContext/DbContext when one is available. However, command trees can be cached, which means sometimes a context will “see” a command tree created and sometimes it will not. Is this an issue?
     - Is it okay, from a perf perspective, for all interceptors of a certain type to be globally registered?
     - Is it okay for the command execution Dispatch methods to also actually execute the command? This makes using the dispatcher super-easy and ensures before and after methods are always called, but in a sense dispatching to interceptors and actually execution could be considered separate concerns.
     - Should command tree dispatch also be public? In general, if we have public interceptors for something, should that thing also be publicly dispatchable?
     - Are there other things we should put in the interception context for EF6?
    ajcvickers committed Apr 25, 2013
  2. Updating NuGet install logic to also remove System.Data.Entity refere…

    …nces from web site projects
    bricelam committed Apr 30, 2013
  3. TheOriginalIsUnfaithfulToTheTranslation - porting the fix to workitem…

    … 184 from the original changes made to Dev11.
    Basically, this change attempts to load the assembly that contains the [ScriptIgnore] attribute and if it succeeds, it instantiates the parameterless constructor info. It is then used to decorate the field when it is marked as not serializable, along with [IgnoreDataMember] and [XmlIgnore].
    See for more details.
    unknown committed with ajcvickers Apr 29, 2013
  4. WolfInEnumsClothing - porting the fix to workitem 596 from the origin…

    …al changes made to Dev11.
    Enums are supported as a feature starting on EDM version 3, which was released with .NET 4.5 as part of EF5. This fix basically inhibits type discovery of enum types when there are enums interacting as part of a Linq query. Instead, we resolve to the underlying type (such as Int32, etc).
    For more details see
    unknown committed with ajcvickers Apr 29, 2013
  5. Migrations: Fix for Migrations: Remove history table metadata from co…

    …de-behind [CodePlex #999]
    - Removes concept of "system" operation from the migrations model.
    - Migration model metadata no longer contains the history context model.
    - The history table is no longer made a SQL Server system object.
    - Keeps the ability to use HasDefaultSchema to affect the history table and support move operations.
    - Maintains detection of invalid history table moves (auto migrations).
    anpete committed Apr 25, 2013
Commits on Apr 29, 2013
  1. Adding update tests. CR: BriceLam

    Maurycy Markowski committed Apr 29, 2013
  2. CodePlex #369: Support Generate Views on EF6: Added Generate methods …

    …on StorageMappingItemCollection and StorageEntityContainerMapping classes and the ContainerMappingViewGroup class
    Emil Cicos committed Apr 29, 2013
  3. ThwartingSupermanIII (Add flag to change truncation behavior for deci…

    …mal parameters)
    This turned out to be an issue with the SQL provider, which meant that the idea of having a flag on the context was not really appropriate. The flag has instead been added as a static on SqlProviderServices, with the idea being that an application that depends on this can set the flag at startup and then forget about it, but we can discuss if there is a better place for it.
    The underlying issue is in SQL Client where if Scale is set on a SqlParameter object then it will cause the value to be truncated. The SqlParameter documentation says that the truncation behavior should not be relied upon, but it seems very unlikely that it will change. The recommended approach is to not set Scale at all for input parameters, which is what EF now does when the flag is set.
    We may want to discuss again the value of changing the default to not truncate. This is a breaking change for anyone relying on the old behavior that would be hard to detect. On the other hand, not changing the default will likely result in hard to find bugs in new applications and may also fix some existing applications that are not aware of and have not tested for the truncation behavior.
    The SQL Compact provider does not appear to have this issue. However, it does always truncate "money" columns, but this appears to be below the level of the provider and there doesn't seem to be a way to influence it from EF.
    ajcvickers committed Apr 28, 2013
  4. YourSecretIdentityIsDiscovered (Uniquify identity instead of name whe…

    …n setting name explicitly)
    This was an issue with the code that temporarily uniquifies identities when multiple column names are explicitly set to the same name but then all but one are removed. In cases where there are a lot of columns in the collection (so that metadata does its collection handling flip) this was causing issues because the names were uniquified but the identities were colliding. The fix is to make sure that identities are uniquified in this case.
    ajcvickers committed Apr 27, 2013
Commits on Apr 28, 2013
  1. NudgeNudgeWinkWinkSayNoMore (Remove call to internal .NET Framework c…

    The call was being using to preserve stack trace information when unwrapping invocation exceptions. This is now being done using ExceptionDispatchInfo on .NET 4.5, and is not being done at all on .NET 4.
    ajcvickers committed Apr 27, 2013
Commits on Apr 26, 2013
  1. Re-enabling tests. Issue was use of SQL Server 2008 (which is flakey …

    …with attached files) instead of SQL Server 2012.
    ajcvickers committed Apr 26, 2013
  2. GACAttack (Make by-convention loading of SQL Server provider use type…

    … name with version and public key token)
    This fixes the issue where the SQL Server provider would fail to load when the EF assemblies are GACed and no provider is registered.
    Since EF is never GACed automatically and bin-deployment is strongly preferred over GACing there is no change made to the entries added in the config file by default. This means that if EF is GACed and the config files are being used, then they may need to be manually updated to contain extra type information. By not doing this for everyone we improve the experience for the vast majority who are not GACing at the expense of an extra step for those who are.
    ajcvickers committed Apr 26, 2013
  3. CodePlex workitem #816: Added code to sort sequences before being enu…

    …merated in order to create a hash that does not depend on the order if items
    Emil Cicos committed Apr 26, 2013
  4. Removed HashOverAllExtentViews and related code (part of CodePlex wor…

    …kitem #606)
    Emil Cicos committed Apr 26, 2013
Commits on Apr 25, 2013
  1. Make GetEntityTypeMappings(this DbDatabaseMapping databaseMapping, En…

    …tityType entityType)
    return an IReadOnlyList<StorageEntityTypeMapping> to eliminate needless .ToList() conversions.
    Leverage when we know a collection has a .Count instead of calling .Any().
    Rename parameter for GetEntityTypeMapping that matches via ClrType to
    correctly reflect what we're looking matching against.
    IDisposable committed with ajcvickers Apr 25, 2013
  2. Pull request for 1050: Adding a RemoveRange API

    This is a contribution from Unai Zorrilla which is similar to the recently submitted AddRange in that it performs the operation on many entities without multiple calls to DetectChanges.
    ajcvickers committed Apr 25, 2013
  3. Pull request for 1043: Add simple and efficient API to ask if there a…

    …re pending changes on a DbContext
    This is a contribution from Unai Zorrilla that adds a context.ChangeTracker.HasChanges method that calls DetectChanges (if enabled) and returns true if SaveChanges would send anything to the database.
    ajcvickers committed Apr 25, 2013
  4. Disabling attached database tests since they consistently fail for me…

    … when running build.cmd.
    They seem to work when run in Visual Studio.
    The tests are disabled to unblock checking in pull requests.
    ajcvickers committed Apr 25, 2013
  5. Migrations: Adds support for scaffolding sprocs for many-to-many asso…

    - Removes temporary provider services sproc body generation API.
    - Changes the way sproc-free models are generated to handle associations.
    - Adds outParameter arg to sproc parameters fluent API scaffolding.
    - Updates differ and command tree generator to handle association sprocs.
    anpete committed Apr 22, 2013
Commits on Apr 24, 2013
  1. NotOnlyElectricEquipmentWorksBetterWhenPluggedIn - invoking writing m…

    …appings for composable functions
    We had code to serialize mappings for composable functions which was never invoked and therefore in the designer
    we would never map function imports to functions we got from the database even though the function imports were
    created based on those functions.
    moozzyk committed Apr 24, 2013
  2. Performance: MemberCollection.GetDeclaredOnlyMembers<T>() is now usin…

    …g a List<T> instead of a MetadataCollection<T> as the underlying data for the ReadOnlyMetadataCollection<T> that it returns. This is safe since the List<T> is being populated from an already-sorted MetadataCollection<T>.
    unknown committed with ajcvickers Apr 2, 2013
  3. Performance: AttributeProvider.GetAttributes() operates on immutable …

    …data. A good performance boost is seen when we cache the results of attributes that have already been resolved for a particular PropertyInfo instance. Furthermore, the instance now behaves like a singleton service from DbConfiguration since AttributeProvider.GetAttributes() is invoked from several places of the EF stack, including the calls to SaveChanges() and they all benefit from sharing the same cache.
    unknown committed with ajcvickers Apr 2, 2013
  4. Performance: DbDatabaseMappingExtensions.GetEntityTypeMapping was spe…

    …nding a sizeable amount of time doing Linq to Objects in this method. A simple rewrite to use simple iterators helps boosting up the performance.
    unknown committed with ajcvickers Apr 2, 2013
  5. Performance: EdmProperty now verifies if the facet values are changin…

    …g. If that's the case, then it proceeds with the change. If the value isn't changing, then it is a no-op. The cost of getting the facet and checking its value before setting it is cheaper than setting the facet to the same value repeatedly, due to the costly use of TypeUsage.ShallowCopy.
    unknown committed with ajcvickers Apr 2, 2013
  6. Performance: Removing EntityType.DeclaredKeyProperties and replacing …

    …it by EntityTypeBase.Keyproperties, avoiding the check to see if the key properties have been declared in the current entity type. Key properties are always declared in the root entity type.
    unknown committed with ajcvickers Apr 2, 2013