You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When you have a project setup as disable, the generated mapping for IQueryable sets the IQueryable code block with #nullable disable but the generated code in the block checks for nulls rather than just doing the straight mapping.
I would expect that for the IQueryable mappings setting Nullable to disable or enable would result in the same IQueryable mapping.
This null checking also results in some incorrect EF Core generated code when you have a child entity and mapping to a DTO.
Environment (please complete the following information):
Mapperly Version: 3.5.1 or 3.6.0 preview
Nullable reference types: disable
.NET Version: 8.0.101
Target Framework: .net8.0
Compiler Version: 4.8.0-7.23572.1 (7b75981c)'.
C# Language Version: 12.0
IDE: Visual Studio 17.8.6
OS: Windows 10
Additional context
The incorrect EF Core generated SQL when the Nullable flag is set to 'disable' is as follows (in particular notice the multiple LEFT JOIN lines):
SELECT0, "c"."Id", "c"."Name", CASE
WHEN "c0"."Name"IS NOT NULL THEN "c0"."Name"
ELSE NULL
END, "c"."Description", "c0"."Id", "c1"."CarrierServiceId", "c1"."CountryCode", 0, "c2"."CarrierServiceId", "c2"."CountryCode"FROM"CarrierServices"AS"c"INNER JOIN"Carriers"AS"c0"ON"c"."CarrierId"="c0"."Id"LEFT JOIN"CarrierServiceCountryInclusions"AS"c1"ON"c"."Id"="c1"."CarrierServiceId"LEFT JOIN"CarrierServiceCountryInclusions"AS"c2"ON"c"."Id"="c2"."CarrierServiceId"ORDER BY"c"."Id", "c0"."Id", "c1"."CarrierServiceId", "c1"."CountryCode", "c2"."CarrierServiceId"
The correct EF Core generated SQL when the Nullable flag is set to 'enable' - and what I'd also expect if the flag was set to 'disable' is:
In another project I've also experienced the null checking output even when the Nullable property is set to 'enable' on the main project.
As it was a larger project, it appears that if there is a referenced project that doesn't have the Nullable property set at all, Mapperly seems to behave as if the Nullable property is set to disable.
Thanks for reporting. Regarding your second comment: it depends on the ef core entity classes respectively their tproperties. Are they in a nullable disabled context?
As for multiple projects and nullable issue - ok, that would explain it then. The solution has been migrated from earlier .net so the Nullable option hasn't been set on all projects - and hence defaults to false - so the entities project would have been seen as Nullable 'false'.
Describe the bug
When you have a project setup as disable, the generated mapping for IQueryable sets the IQueryable code block with #nullable disable but the generated code in the block checks for nulls rather than just doing the straight mapping.
I would expect that for the IQueryable mappings setting Nullable to disable or enable would result in the same IQueryable mapping.
This null checking also results in some incorrect EF Core generated code when you have a child entity and mapping to a DTO.
Declaration code
Actual relevant generated code
Expected relevant generated code
Environment (please complete the following information):
Additional context
The incorrect EF Core generated SQL when the Nullable flag is set to 'disable' is as follows (in particular notice the multiple LEFT JOIN lines):
The correct EF Core generated SQL when the Nullable flag is set to 'enable' - and what I'd also expect if the flag was set to 'disable' is:
The text was updated successfully, but these errors were encountered: