Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Commits on Aug 15, 2013
  1. @marek-safar

    Merge pull request #2 from bricelam/master

    marek-safar authored
    Update to 6.0.0-beta1
Commits on May 16, 2013
  1. @bricelam
Commits on May 10, 2013
  1. @bricelam

    Revert "Updating NuGet install logic to also remove System.Data.Entit…

    bricelam authored
    …y references from web site projects"
    This reverts commit c0da429.
Commits on May 1, 2013
  1. @ajcvickers
  2. @ajcvickers

    DidIReallyDoThat (Fixing net40 test failures due to async operations …

    ajcvickers authored
    …not being run in net40 tests)
  3. @ajcvickers

    LexLutherStrikesBack (Fix additional bug around decimal scale/precision)

    ajcvickers authored
    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.
Commits on Apr 30, 2013
  1. @ajcvickers

    EveryStepYouTake... (Building blocks for interception)

    ajcvickers authored
    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?
  2. @bricelam

    Updating NuGet install logic to also remove System.Data.Entity refere…

    bricelam authored
    …nces from web site projects
  3. @ajcvickers

    TheOriginalIsUnfaithfulToTheTranslation - porting the fix to workitem…

    unknown authored ajcvickers committed
    … 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.
  4. @ajcvickers

    WolfInEnumsClothing - porting the fix to workitem 596 from the origin…

    unknown authored ajcvickers committed
    …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
  5. @anpete

    Migrations: Fix for Migrations: Remove history table metadata from co…

    anpete authored
    …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).
Commits on Apr 29, 2013
  1. Adding update tests. CR: BriceLam

    Maurycy Markowski authored
  2. CodePlex #369: Support Generate Views on EF6: Added Generate methods …

    Emil Cicos authored
    …on StorageMappingItemCollection and StorageEntityContainerMapping classes and the ContainerMappingViewGroup class
  3. @ajcvickers

    ThwartingSupermanIII (Add flag to change truncation behavior for deci…

    ajcvickers authored
    …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.
  4. @ajcvickers

    YourSecretIdentityIsDiscovered (Uniquify identity instead of name whe…

    ajcvickers authored
    …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.
Commits on Apr 28, 2013
  1. @ajcvickers

    NudgeNudgeWinkWinkSayNoMore (Remove call to internal .NET Framework c…

    ajcvickers authored
    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.
Commits on Apr 26, 2013
  1. @ajcvickers

    Re-enabling tests. Issue was use of SQL Server 2008 (which is flakey …

    ajcvickers authored
    …with attached files) instead of SQL Server 2012.
  2. @ajcvickers

    GACAttack (Make by-convention loading of SQL Server provider use type…

    ajcvickers authored
    … 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.
  3. CodePlex workitem #816: Added code to sort sequences before being enu…

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

    Emil Cicos authored
    …kitem #606)
Commits on Apr 25, 2013
  1. @ajcvickers
  2. @IDisposable @ajcvickers

    Make GetEntityTypeMappings(this DbDatabaseMapping databaseMapping, En…

    IDisposable authored ajcvickers committed
    …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.
  3. @ajcvickers
  4. @ajcvickers

    Pull request for 1050: Adding a RemoveRange API

    ajcvickers authored
    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.
  5. @ajcvickers
  6. @ajcvickers

    Pull request for 1043: Add simple and efficient API to ask if there a…

    ajcvickers authored
    …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.
  7. @ajcvickers

    Disabling attached database tests since they consistently fail for me…

    ajcvickers authored
    … when running build.cmd.
    They seem to work when run in Visual Studio.
    The tests are disabled to unblock checking in pull requests.
  8. @anpete

    Migrations: Adds support for scaffolding sprocs for many-to-many asso…

    anpete authored
    - 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.
Commits on Apr 24, 2013
  1. @moozzyk

    NotOnlyElectricEquipmentWorksBetterWhenPluggedIn - invoking writing m…

    moozzyk authored
    …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.
  2. @ajcvickers
  3. @ajcvickers

    Performance: MemberCollection.GetDeclaredOnlyMembers<T>() is now usin…

    unknown authored ajcvickers committed
    …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>.
  4. @ajcvickers

    Performance: AttributeProvider.GetAttributes() operates on immutable …

    unknown authored ajcvickers committed
    …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.
  5. @ajcvickers

    Performance: DbDatabaseMappingExtensions.GetEntityTypeMapping was spe…

    unknown authored ajcvickers committed
    …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.
  6. @ajcvickers

    Performance: EdmProperty now verifies if the facet values are changin…

    unknown authored ajcvickers committed
    …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.
  7. @ajcvickers

    Performance: Removing EntityType.DeclaredKeyProperties and replacing …

    unknown authored ajcvickers committed
    …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.
Something went wrong with that request. Please try again.