Feature Request: Global Default for `NullConditionalRewriteSupport`

[Seramis]

Currently, the NullConditionalRewriteSupport setting on the [Projectable] attribute defaults to NullConditionalRewriteSupport.None if not explicitly specified. While this provides granular control, I've found that in many projects, the decision regarding null conditional rewrites is a system-wide consideration rather than being property-specific. This leads to repetitive boilerplate code, as I frequently have to explicitly set NullConditionalRewriteSupport.X on numerous [Projectable] attributes throughout the codebase, even when the desired behavior is consistent across the application. This becomes quite tiresome and can clutter the code.

Proposal

I propose enhancing the ProjectableOptionsBuilder to include an option for setting the default NullConditionalRewriteSupport. The UseProjectables() method in EntityFrameworkCore.Projectables.Extensions.DbContextOptionsExtensions.cs already accepts an Action<ProjectableOptionsBuilder>? configure argument. My suggested solution is to extend the ProjectableOptionsBuilder (defined in EntityFrameworkCore.Projectables.Infrastructure.ProjectableOptionsBuilder.cs) to allow developers to configure this global default directly when enabling Projectables.

This would allow for a clean and centralized configuration, for example:

dbContextOptions.UseProjectables(options =>
{
    options.SetDefaultNullConditionalRewriteSupport(NullConditionalRewriteSupport.X);
});

This approach aligns well with how other Entity Framework Core options are typically configured within the DbContextOptions setup, providing a consistent and intuitive way to manage projectable-specific settings. When a [Projectable] attribute does not explicitly define NullConditionalRewriteSupport, it would then fall back to the value set via SetDefaultNullConditionalRewriteSupport.

Alternatives

I have considered the current approach of manually setting NullConditionalRewriteSupport on each [Projectable] attribute. However, as described, this leads to significant repetition and maintainability overhead in projects where a consistent null conditional rewrite strategy is desired across many projected properties.

Another alternative would be to introduce a static global default setting, for instance, EntityFrameworkCore.Projectables.NullConditionalRewriteSupportDefault. This static property could be initialized with NullConditionalRewriteSupport.None and then overridden early in the application's lifecycle, such as in Program.cs. While functional, I believe the ProjectableOptionsBuilder approach offers better integration with the existing DbContextOptions configuration flow and provides a more encapsulated way to manage projectable-specific options.

Additional context

This feature would greatly improve developer experience and reduce code verbosity for projects utilizing EntityFrameworkCore.Projectables where a consistent null conditional rewrite strategy is preferred. It would allow for a cleaner and more concise declaration of projectable properties by removing the need to repeatedly specify the same NullConditionalRewriteSupport value.

[Seramis]

I have played around implementing this feature myself.

I've found that this setting needs to be present during compilation as this affects the behavior of the code generator. Therefore, it can not be implemented as part of the Options Builder as I have suggested earlier.

What I believe could be done is a property in .csproj file that the generator will then read. (For example Projectables_DefaultNullRewriteSupport) That property will be read by ProjectionExpressionGenerator and passed forward to ProjectableInterpreter.GetDescriptor which then in turn can use this default value information. The enum itself needs to get an additiona enum value (for example GlobalDefault) as a default enum value (position 0) and during the execution of ProjectableInterpreter.GetDescriptor if it sees that the the value from the [Projectable] attribute is GlobalDefault it can override that with the default value passed in by the ProjectionExpressionGenerator.

I think I have working code, but I'm not very versed in source code generators and therefore I'm unable to properly identify how (if at all) I could write tests for it. I could make a PR that should be implementing this feature if you are willing to look into it and add necessary tests and details by yourself.

@koenbeuk, would it be something you would be interested in?