This page is no longer being updated. Changes that provider authors need to be aware of are marked with providers-beware.
This page contains links to pull requests made on the EF Core repo that may require authors of other database providers to react. The intention is to provide a starting point for authors of existing third-party database providers when updating their provider to a new version.
We are starting this log with changes from 2.1 to 2.2. Prior to 2.1 we used the providers-beware and providers-fyi labels on our issues and pull requests.
Explicit configuration of log levels required some changes to APIs that providers may be using. Specifically, if providers are using the logging infrastructure directly, then this change may break that use. Also, Providers that use the infrastructure (which will be public) going forward will need to derive from LoggingDefinitions or RelationalLoggingDefinitions. See the SQL Server and in-memory providers for examples.
Core, Relational, and Abstractions resource strings are now public.
CoreLoggerExtensions and RelationalLoggerExtensions are now public. Providers should use these APIs when logging events that are defined at the core or relational level. Do not access logging resources directly; these are still internal.
IRawSqlCommandBuilder has changed from a singleton service to a scoped service
IMigrationsSqlGenerator has changed from a singleton service to a scoped service
This change is fully covered in the application breaking changes document. For providers, this may be more impacting because testing EF core can often result in hitting this issue, so test infrastructure has changed to make that less likely.
Data seeding has been refactored into a public API to avoid the need to use internal types. This should only impact non-relational providers, since seeding is handled by the base relational class for all relational providers.
Changes in 2.1 to the RelationalTypeMapping allowed for a simplification in derived classes. We don't believe this was breaking to providers, but providers can take advantage of this change in their derived type mapping classes.
Adds infrastructure for tagging LINQ queries and having those tags show up as comments in the SQL. This may require providers to react in SQL generation.
This PR adds the concept of CanConnect which will be used by ASP.NET Core health checks to determine if the database is available. By default, the relational implementation just calls Exist, but providers can implement something different if necessary. Non-relational providers will need to implement the new API in order for the health check to be usable.
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
.NET feedback
.NET is an open source project. Select a link to provide feedback:
SQL Server 2022 introduces a range of new features and enhancements, providing powerful tools and capabilities that optimize performance and offer better control on SQL objects manipulation and creation.