.Net: [MEVD] Ensure columns nullability is correct across providers

[roji]

Our SQL Server provider seems to always create non-nullable columns, regardless of the .NET type, whereas our PG provider varies based on whether the .NET type is nullable. Do a pass over the relational providers to ensure everything makes sense. I'm not sure any non-relational provider allows defining the nullability of properties/columns, but worth checking to make sure (Azure AI Search seems to maybe have a concept of nullability in its schema).

We may also want to introduce a way for the user to control the column nullability regardless of the .NET type used, that would likely require #10359.

[SuvitKumar003]

Hey,
I would like to contribute to this issue and i have also understood the issue a bit for clarity, can anyone help me in this issue

[roji]

@SuvitKumar003 what exact changes are you proposing to make?

[SuvitKumar003]

Hey @roji ,
I’ve done an initial investigation into the nullability behavior differences between providers, as discussed.
At line 1670 in SqlServerMigrationsSqlGenerator.cs, I found the column nullability is handled as follows:
--> builder.Append(operation.IsNullable ? " NULL" : " NOT NULL");

At line 1169 in MigrationsModelDiffer.cs, where AddColumnOperation is created, I noticed that IsNullable was not being set, which is likely the root cause.

Because IsNullable defaults to false, this caused SQL Server to always generate NOT NULL, even for nullable .NET properties like string? or int?.
Fix i made:
I added the following line during the AddColumnOperation setup to propagate correct nullability from the model:
IsNullable = target.IsNullable,

I’m currently testing the fix by creating a model with both nullable and non-nullable properties and verifying the generated SQL.

Let me know if this approach makes sense — I’ll be happy to submit a PR after validating the results.
I am also sharing the proper file path for the changes made above to save your time for finding the targetted location
--> src/EFCore.SqlServer/Migrations/SqlServerMigrationsSqlGenerator.cs → (line 1670)
--> src/EFCore.Relational/Migrations/Internal/MigrationsModelDiffer.cs → (line 1169)

Thanks!

[roji]

@SuvitKumar003 your comment seems to be about EF Core, but this is MEVD. If your intention is simply to have AI submit the PR, please don't do that (although it's of course perfectly fine to use the help of AI when working on a PR).

[SuvitKumar003]

Hello @roji Sir,
Sir I agree that i used AI in this ,actually currently I am currently towards my 4th year of my B.Tech degree in Computer Engneering and i wanted to explore all the possible option that are there in the market so Open Source was one of them and I am purely new to this. Sir you are the first person who replied to my comment and I am very thankful to that .
Although i used chatgpt to make the changes but i also understood how the process works and how to find the concerned files and how to look into the code before doing the OSS in C# i learned it so that it can be easy for me.
I thank you for pointing me out. This advice will help me in future, meanwhile, I will also correct this issue using myself and AI.
I would like to ask, Sorry for my work, but I will definitely give you the corrected work!!
Regards
Suvit Kumar

[SuvitKumar003]

Hello @roji Sir,
Sir I looked for the issue in the correct repo and looked for why the issue is coming so i found the responsible files for this issue but what I found for this is that they are already correctly classified and are working as requried .
For this purpose I looked into three files namely
1.PostgressSqlBuilder.cs -> It creates Table
2.PostgresPropertymappingTests.cs -> Calculate the Type and determine if a column should be nullable
3.PostgresPropertyMapping.cs ->It checks for the returned values are correct.
As a fresher and a Learner, I am asking you to dive deep into this and help me out to correctly classify the issue and make it correct.
I hope you will help me out and will let me carry forward the work .
Regards
Suvit Kumar