…y references from web site projects" This reverts commit c0da429.
…not being run in net40 tests)
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.
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?
…nces from web site projects
… 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 http://entityframework.codeplex.com/workitem/184 for more details.
…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 http://entityframework.codeplex.com/workitem/596.
…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).
…on StorageMappingItemCollection and StorageEntityContainerMapping classes and the ContainerMappingViewGroup class
…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.
…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.
…ode) 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.
…with attached files) instead of SQL Server 2012.
… 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.
…merated in order to create a hash that does not depend on the order if items
…ilable in .NET 4.
…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.
…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.
… when running build.cmd. They seem to work when run in Visual Studio. The tests are disabled to unblock checking in pull requests.
…ciations. - 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.
…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.
…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>.
…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.
…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.
…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.
…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.