Unexpected behavior for non-optional complex type where all properties are nullable

[dkokotov]

Question

It is great that in .NET 10 support for optional/nullable complex properties was added. However, as part of this the release notes mention "Note that optional complex types currently require at least one required property to be defined on the complex type.". But it's unclear what the expected behavior is in that case, and if it's different depending on whether the property for the complex type is nullable or not.

In my scenario, I previously had a data model like this:

public class Project {
    public string Id { get; set; }
    public Lifetime Lifetime { get; set; 
}

public class Lifetime {
    public DateTime? Start { get; init; }

    public DateTime? End { get; init; }
}

Project.Lifetime was mapped as complex property. Note that the modeling is like this because all 4 combinations of Lifetime.Start and Lifetime.End nullability are possible.

In EF 9, if both were null, this was retrieved as as a not-null Lifetime with both Start and End null. But in .NET 10, this is retrieved as a null Lifetime - even though it is still declared as a not-null property. this is then breaking some downstream code.

I can deal with this (I guess by changing Project.Lifetime to be nullable), my question is whether it is expected behavior. I couldn't find documentation of Complex Type for EF 10 other than the single mention in the "what's new" above. And I tried to read the discussion in #31376 but I am still somewhat confused as to what is supported / expected in this case, and whether the observed behavior is what is expected or not.

It would be great if the documentation was updated to discuss this. Also any advice as to what I should do in the meantime would be very appreciated.

Your code

Stack traces

Verbose output

EF Core version

10.0.0

Database provider

Npgsql

Target framework

.NET 10

Operating system

Mac OS

IDE

Rider

[rbakhshi]

If you make LifeTime nullable, would it then ask you to provide a Discrimnator ?

[dkokotov]

@rbakhshi good question, yes in this case it does - without a Discriminator and with Lifetime nullable I get this error:

An unexpected error occurred: System.InvalidOperationException: The optional complex property 'Project.Lifetime#Lifetime.Lifetime' is mapped to columns by flattening the contained properties into its container's table; this mapping requires at least one required property - to allow distinguishing between 'null' and empty values - but the complex type contains only optional properties. Configure the property with a shadow discriminator by adding a call to 'HasDiscriminator()' on the complex property configuration, or map this

That does match what the EF 10 release notes say about optional complex types requiring at least one not nullable property (though I could find nothing in the official documentation about this discriminator concept).

This makes me think the current behavior with Lifetime not nullable is a regression and it should continue to behave as it did in EF 9.

[roji]

Confirmed, this seems to be a regression - see minimal repro.

Minimal repro

await using var context = new BugDbContext();
await context.Database.EnsureDeletedAsync();
await context.Database.EnsureCreatedAsync();

context.Projects.Add(new()
{
    Lifetime = new Lifetime()
});
await context.SaveChangesAsync();

context.ChangeTracker.Clear();

var project = await context.Projects.SingleAsync();
Console.WriteLine(project.Lifetime is null); // Prints true

public class BugDbContext : DbContext
{
    public DbSet<Project> Projects { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        => optionsBuilder
            .UseSqlServer("Server=localhost;Database=test;User=SA;Password=Abcd5678;Connect Timeout=60;ConnectRetryCount=0;Encrypt=false")
            .LogTo(Console.WriteLine, LogLevel.Information)
            .EnableSensitiveDataLogging();

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Project>().ComplexProperty(p => p.Lifetime).IsRequired(true);
    }
}

public class Project
{
    public int Id { get; set; }
    public Lifetime Lifetime { get; set; }
}

public class Lifetime
{
    public DateTime? Start { get; init; }
    public DateTime? End { get; init; }
}

[roji]

Confirmed regression in #36550, commit 38fbaf9. The precise problem is here: we previously checked whether the complex property is nullable, whereas this PR changed it to look only at the CLR type. Classes are of course nullable types, but that doesn't mean that the complex type is nullable.

/cc @cincuranet