EF Core provides a variety of ways to start tracking entities or change their state. This post gives a brief overview of the different approaches.
As developers on the EF team it is often useful to see what is in the metadata model. To facilitate this, the model and all other metadata elements are able to generate a “debug view” which provides lots of useful information about the metadata in a terse but human-readable form.
By default, EF Core uses snapshot change tracking. However, if entity types implement INotifyPropertyChanged and optionally INotifyPropertyChanging, then EF can use these notifications to avoid the overhead of creating snapshots and detecting changes.
Writing a database provider for EF Core can be daunting. I have written several posts over the last month containing information you need to know when writing a provider. This post pulls all that together to give an overview of the different building blocks with links to previous posts containing the details.
A previous post gave an outline of EF Core metadata. That post showed the extension methods used by providers to add provider-specific functionality to EF. This post describes how to implement those methods. This post is aimed at provider writers or those who may want to contribute to the EF Core source code.
There is very little code in EF Core that is truely “internal”. Instead, code that would traditionally have been internal has been made public but documented as internal. This post looks at what this means for application developers and how you can use this code responsibly.
This post provides a high-level overview of metadata structure and APIs in EF Core 1.1. It covers the core metadata interfaces and shows how they are extended with particular focus on provider extensions.