Ever since POCO support was introduced in EF4 there have been two limiting restrictions on the types that can be mapped:
Types nested inside other types were not supported
Types were matched by simple names only
Some recent check-ins to the EF6 code base have lifted these restrictions to some degree when using Code First. This post describes what is now supported, what restrictions still exist, and provides some background about why things are the way they are. Continue reading →
It is common for a single parent entity to be related to many child entities. This relationship may be required or optional. A required relationship means that the child cannot exist without a parent, and if the parent is deleted or the relationship between the child and the parent is severed, then the child becomes orphaned. In such situations it is often useful to have the orphaned child automatically deleted. Continue reading →
Code First’s convention-based approach to building a model has some interesting implications for breaking changes between different versions of EF. This post describes those implications and shows how model builder versions can be used to deal with potential breaking changes while still retaining a forward-moving developer experience. Continue reading →
There are plenty of examples out there showing how to use DbContext to create a Code First model. But DbContext itself uses some fundamental Code First building blocks to do its stuff. This post shows how these building blocks can be used directly, which can be useful in situations where you need more control over how the model is created or cached. Continue reading →
The Entity Framework supports mapping to public, protected, internal, and private properties. However, there are a few restrictions when mapping to non-public properties. and there are also some things you need to know when attempting to configure such mappings using Code First. In particular, mapping to non-public properties cannot be done using data annotations alone.
You have probably heard about the high-profile features of EF5—things like enums, spatial types, TVF support, and the perf improvements. But there is one little feature you may not have heard about—the ability to reject changes to an individual property. That is, to reset the IsModified flag of a property such that the value of that property will not be sent to the database.
Code First Migrations uses a table called __MigrationHistory as a place to store metadata about the migrations that have been applied to the database. Code First creates this table when it creates a database or when migrations are enabled. In addition, when running against Microsoft SQL Server, Code First will also mark the table as a system table. However, several times recently the question has come up of how to make the table a normal user table instead of a system table. This is pretty easy to do and this post describes how.