Entity Framework Core interview questions covering migrations, schema changes, indexes, keys, defaults, computed columns and data management.
Open a question for the full answer, code and interview guidance.
EF Core migrations provide a versioned way to evolve a relational database schema as the application's EF Core model changes. A migration can describe operations such as creating or dropping tables, adding or altering columns, creating indexes, and changing constraints.
When a new migration is created, EF Core compares the current model with the model snapshot associated with the previous migration. The differences are converted into migration operations.
The Up method describes how to move the database forward to the migration's schema state. The Down method describes how to reverse that migration when a rollback is supported.
The __EFMigrationsHistory table records which EF Core migrations have been applied to a database. EF Core uses it to determine which migrations are still pending.
EF Core tooling can list migrations known to the project, while application APIs can inspect applied and pending migrations for a database.
Update-Database applies migrations to the configured database until it reaches the requested migration, or the latest migration when no target is specified.
If the most recent migration has not been applied where it matters and no later migration depends on it, EF Core tooling can remove that migration and update the model snapshot.
EF Core tooling can generate SQL representing migration operations. A SQL script can be reviewed, archived, tested, and executed by a database administrator or deployment pipeline.
An idempotent EF Core migration script contains logic that applies only migrations that have not already been recorded as applied. This allows the same script to be used against databases that may be at different known migration levels.
Calling Database.Migrate at startup can be convenient for simple or tightly controlled deployments, but it is not universally appropriate.
EnsureCreated creates a database schema directly from the current EF Core model when the database does not exist. It does not establish the normal migrations history used for incremental schema evolution.
EF Core can map entity types and properties to specific table and column names using data annotations or the Fluent API.
Property configuration can specify maximum length, requiredness, precision, and provider-specific database column types.
A property can be configured with a database default value or default SQL expression. The database uses the default when an INSERT does not provide a value for that column according to the mapping.
A computed column is calculated by the database from an expression rather than being supplied directly by ordinary application inserts and updates.
Indexes can be configured in the EF Core model with HasIndex. A migration can then create the corresponding database index.
A unique index enforces that the indexed key value or key combination cannot be duplicated according to the database's uniqueness semantics.
A composite key uses more than one property to uniquely identify an entity. It is common in explicit join entities and some legacy database schemas.
An alternate key is an additional candidate key that uniquely identifies an entity besides its primary key. EF Core relationships can target an alternate key.
For databases that support schemas, EF Core can map a table to a named schema. This can help organize database objects or integrate with an existing database design.
HasData configures model-managed seed data. EF Core migrations detect changes to this configured data and can generate insert, update, or delete operations.
A model rename may sometimes be interpreted as removing the old database object and creating a new one. If a generated migration drops a column and adds another, existing data can be lost.
Destructive changes such as dropping columns, shrinking data types, or changing constraints should be planned around existing data and application compatibility.
A migration can execute SQL directly through migrationBuilder.Sql when an operation cannot be conveniently expressed by standard migration APIs.
Keep migration files and the model snapshot in source control, give migrations meaningful names, and review generated operations before committing or deploying them. Never assume generated schema changes are automatically safe.