Mapping Option<T> to nullable column

[burikella]

In effort to reduce null values in the codebase, I'm trying to use LanguageExt library which provides Option<T> type.
I've tried to map an entity with such property to the nullable column and got an error:

The property 'Entity.Title' cannot be marked as nullable/optional because the type of the property is 'Option' which is not a nullable type. Any property can be marked as non-nullable/required, but only properties of nullable types can be marked as nullable/optional.

The error sounds reasonable, since EFCore doesn't have any special treatment for the Option<T> type. So I've tried to add conversion to string? assuming that EFCore will see string? as a type that should be mapped to data storage, however, the error remains the same.

Is there any reason for the original property's CLR Type being used in that check?
Is there any workarounds for this issue?
Any extension points in EFCore I can leverage to handle the case?

The repro sample is following console app (repro project attached):

using LanguageExt;
using Microsoft.EntityFrameworkCore;

Console.WriteLine("Hello, World!");

class DataContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer();
        base.OnConfiguring(optionsBuilder);
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Entity>(builder =>
        {
            builder.HasKey(e => e.Id);
            builder.Property(e => e.Id);
            builder.Property(e => e.Title)
                .HasConversion<string?>(
                    v => v.Match<string?>(x => x, () => null),
                    v => v)
                .IsRequired(false)
                .HasMaxLength(50);
        });

        base.OnModelCreating(modelBuilder);
    }
}

public class Entity
{
    public int Id { get; set; }
    public Option<string> Title { get;set; }
}

EF Core version: 8.0.10
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET 8.0

EFCoreOptionRepro.zip

[roji]

Before digging deeper into the actual error, I'll point out that if you use a value converter like this, you'll lose the ability to do any sort of method/function translations inside LINQ queries. For example, you will be unable to check whether your string contains some character (e.g. context.Set<Entity>().Where(e => e.Title.Value.Contains("foo")). This is a fundamental limitation of using value converters.

.NET has a nullable reference types, which is the standard way of expressing the absence of a value. While NRTs may not be perfect, I recommend against going with a custom 3rd-party Option type.

[burikella]

@roji Thank you for prompt reply! Yeah, it might not worth the price to jump into using some third-party types, however, I wanted to give it a shot to get a clear understanding on where exactly limitations are. And so far it seems the limitations are artificial ones like the error I've started from.

I understand that EF does not include any method translations for such Option type, however, my understanding is that I can easily overcome this limitation by adding some conversion method with corresponding translation, e.g.:
public static string? Raw(this Option<string> value) => throw new NotImplementedException();

And having that I can use a LINQ:
var list = await context.Set<Entity>().Where(e => e.Title.Raw().Contains("Cap")).ToListAsync();

This works just fine and I'm getting correct SQL:

SELECT [e].[Id], [e].[Title]
FROM [Entities] AS [e]
WHERE [e].[Title] LIKE '%Cap%'

The only problems so far are explicit null checks in EF Core against original CLR type: whenever I try to set IsRequired(false) for code-first migrations, or try to read a null-value, I'm getting an error which is based on the type of property completely ignoring the conversion.

[roji]

I understand that EF does not include any method translations for such Option type, however, my understanding is that I can easily overcome this limitation by adding some conversion method with corresponding translation, e.g.:

Right, you're likely to be able to do some things here, but you're also likely to hit some limitations and edge cases where things won't work properly.

Your original error about the Option type not being compatible with optional comes from the fact that it's a value type, and EF has no way of knowing when it's set and when it isn't. This is something we could support (and we've had related discussions recently) - I opened #34943 to track that specific thing.

Otherwise, for your null checks issues which ignore the conversion, could you open a separate issue with a minimal repro for us to investigate?

[roji]

@AndriySvyryd not sure if we have something to investigate or track here - the original question seems to be captured by #34943 (support optional value type properties). I'll go ahead and remove myself as assignee and think we should be able to close this - feel free to do so.

[burikella]

Your original error about the Option type not being compatible with optional comes from the fact that it's a value type, and EF has no way of knowing when it's set and when it isn't. This is something we could support (and we've had related discussions recently) - I opened #34943 to track that specific thing.

What I'm not getting here is why we're looking at the property type, rather than the conversion target type?
It is clear that EF doesn't know how to map value type to null or vice versa, but I have defined conversion to nullable type. So I'm basically giving that information and now EF can deal with string? and forget about original property type being something else.

[roji]

@burikella EF's change tracking (e.g. the check whether a property has changed) happens before any sort of value conversion; the latter occurs only later, when a value needs to be written to the database. I'm not sure what the exact pros and cons would be of changing to change-track after value conversion - this is something we'd need to think about (but there's very little chance we'd change this behavior, I think).

[AndriySvyryd]

The workaround of using a value converter would work after #13850

[ajcvickers]

Looks more like a duplicate of #24685.