Owned entity foreign‑key column missing when owner property is nullable

Direct Answers

1. Yes, EF Core generates a nullable FK column when the referenced owner property is nullable. The FK column's nullability mirrors the owner property's nullability.
2. Composite primary keys on the owner can cause EF Core to embed the owned type's FK into the owner's key columns instead of creating a separate column, unless the owned type defines its own separate primary key.
3. Explicit configuration using OwnsOne(..., b => b.HasForeignKey(...)) or OwnsOne(..., b => b.Property(p => p.OwnerId).IsRequired(false)) resolves ambiguous FK generation when multiple owned types reference the same owner property.

How EF Core Decides FK Column Generation

EF Core maps owned types to the same table as the owner by default. When an owned type references a property of its owner (e.g., a navigation or scalar property), the FK column is created in the owned type's table representation. The nullability of that FK column follows the nullability of the referenced owner property: a nullable owner property produces a nullable FK column; a non-nullable owner property produces a non-nullable FK column.

Composite Primary Key on the Owner

If the owner entity has a composite primary key, EF Core may merge the owned type's FK into the existing key columns. This happens when the owned type does not declare its own primary key. The owned type then shares the owner's composite key, and no separate FK column appears. If the owned type does define a separate primary key (via HasKey in the owned type's configuration), a dedicated FK column is always created regardless of the owner's key structure.

Multiple Owned Types Referencing the Same Owner Property

When two or more owned types reference the same owner property, EF Core cannot infer which owned type owns the FK column, leading to ambiguous migrations or duplicate column errors. You must disambiguate by explicitly configuring the FK for each owned type.

Configuration Steps

1. In OnModelCreating, configure each owned type with OwnsOne and chain HasForeignKey to point to a distinct property on the owned type:

   modelBuilder.Entity<Owner>()
       .OwnsOne(o => o.OwnedA, a =>
       {
           a.HasForeignKey("OwnerIdA");
           a.Property("OwnerIdA").IsRequired(false); // nullable FK
       })
       .OwnsOne(o => o.OwnedB, b =>
       {
           b.HasForeignKey("OwnerIdB");
           b.Property("OwnerIdB").IsRequired(false);
       });

2. If the owned type should have its own primary key, call HasKey inside the owned type configuration:

   .OwnsOne(o => o.OwnedA, a =>
   {
       a.HasKey("Id");
       a.HasForeignKey("OwnerIdA");
   });

3. For nullable owner properties, ensure the FK property is configured as nullable (.IsRequired(false)) to match. For non-nullable owner properties, omit IsRequired(false) or call .IsRequired().

Verification

1. Run dotnet ef migrations script and inspect the generated SQL for the owned type's table. Confirm the FK column exists and its NULL/NOT NULL constraint matches expectations.
2. After applying migrations (dotnet ef database update), check the model snapshot (Migrations/...ModelSnapshot.cs) for the column's IsNullable attribute.

One Diagnostic Detail Needed

Does the owned type define its own primary key (via HasKey or a key property), or does it rely on the owner's key? This determines whether a separate FK column is created or the FK is merged into a composite key.