-
-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected IQueryable mapping when project's Nullable flag is set to "disable" #1293
Comments
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. Possibly a separate issue? |
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? |
@latonz happy to help. 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'. |
Not sure if this is the same issue but I just stumbled over this: public class MyEntity
{
public Guid MyChildId { get; set; }
public MyChildEntity Child { get; set; }
}
public class MyChildEntity
{
public Guid Id { get; set; }
public string Name { get; set; }
}
public class MyDto
{
public Guid Id { get; set; }
public string Name { get; set; }
}
[Mapper]
[UseStaticMapper(typeof(UserRoleMapper))]
public static partial class TestProjectionMapperly
{
public static partial IQueryable<MyDto> ProjectToDto(this IQueryable<MyEntity> source);
[MapProperty(nameof(MyEntity.MyChildId), nameof(MyDto.Id))]
[MapProperty(nameof(MyEntity.Child.Name), nameof(MyDto.Name))]
[UserMapping]
private static partial MyDto MapToDto(this MyEntity source);
} In a .Net 7 Project without explicit nullable switch (which I believe resolves to disabled?) generates // <auto-generated />
#nullable enable
namespace Werma.WeAssist.UserManagement.Application.Mappers
{
public static partial class TestProjectionMapperly
{
[global::System.CodeDom.Compiler.GeneratedCode("Riok.Mapperly", "4.1.0.0")]
public static partial global::System.Linq.IQueryable<global::MyNameSpace.Mappers.MyDto?>? ProjectToDto(this global::System.Linq.IQueryable<global::MyNameSpace.Mappers.MyEntity?>? source)
{
if (source == null)
return default;
#nullable disable
return System.Linq.Queryable.Select(
source,
x => new global::MyNameSpace.Mappers.MyDto()
);
#nullable enable
}
[global::System.CodeDom.Compiler.GeneratedCode("Riok.Mapperly", "4.1.0.0")]
private static partial global::MyNameSpace.Mappers.MyDto? MapToDto(this global::MyNameSpace.Mappers.MyEntity? source)
{
if (source == null)
return default;
var target = new global::MyNameSpace.Mappers.MyDto();
target.Id = source.MyChildId;
target.Name = source.Child?.Name;
return target;
}
}
} Adding // ...
#nullable disable
return System.Linq.Queryable.Select(
source,
x => new global::MyNameSpace.Mappers.MyDto()
{
Id = x.MyChildId,
Name = x.Child.Name,
}
);
#nullable enable Mapperly 4.1.0 |
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: