IQueryable doesn't work with non parameterless ctors

[arkchor]

Describe the bug
It's impossible to generate mapping for IQueryable<T> when there is a non nullable, non parameterless ctor type in mapped object.
Project with such code has compilation error.
Error in such case is: Error RMG002 : {SomeType} has no accessible parameterless constructor.

To Reproduce
Steps to reproduce the behavior:

1. Prepare some value object
   public record ValueObject(string Value);
2. Prepare entity to map from

public class TestEntity
{
    public ValueObject ValueObject { get; set; }
}

3. Prepare dto to map to
   public record TestDto(ValueObject ValueObject);
4. Prepare IQueryable<T> mapper

[Mapper]
public static partial class TestMapper
{
    public static partial IQueryable<TestDto> SelectDto(this IQueryable<TestEntity> test);
}

5. Build

Expected behavior

• Build should pass
• SelectDto should properly perform mapping when used

Code snippets
Generated mapping seems to be fine:

    public static partial class TestMapper
    {
        public static partial global::System.Linq.IQueryable<global::Test.TestDto> SelectDto(this global::System.Linq.IQueryable<global::Test.TestEntity> test)
        {
#nullable disable
            return System.Linq.Queryable.Select(test, x => new global::Test.TestDto(x.ValueObject));
#nullable enable
        }
    }

Environment (please complete the following information):

• Mapperly Version: 3.3.0-next.3
• .NET Version: 8
• Target Framework: net8.0
• IDE: Rider 2023.2.3
• OS: Windows

Additional context
I found a workaround for the problem. It works when we make the type in dto nullable.
So instead of this:
public record TestDto(ValueObject ValueObject);
Make this:
public record TestDto(ValueObject? ValueObject);

I'm very much into DDD and always choose tooling that gives ability to preserve fundamental concepts of DDD.
All above is just example but in real cases I'm implementing I don't want to introduce false statement that something is nullable when in real domain it isn't and should be always there.

Also I would appreciate if somebody could explain me why such error ever happen? What internally leads to the necessity of having parameterless ctors on things when the actual generated code even doesn't need this?
There are more issues related with this (see below) and also I wasn't able to generate mappings for common stuff like IReadOnlyList, IReadOnlyDictionary with same no accessible parameterless constructor error but I don't elaborate on this since somehow I believe the reasoning behind could be same for all cases. But still it's strange for me I can't do it for example for list when below you can see similar issue exactly related to list interfaces that has been closed. I want to better understand internals or maybe there is some common factor across these issues that can be fundamentally solved in design?

Related issues

• List interfaces cannot be mapped to #247
• Support System.Collections.Immutable types #250

[latonz]

Thanks for opening this issue. I'm not sure if I get all of it correctly, can you perhaps create a minimal replication repository on GitHub? You mention a nullable constructor parameter works around the issue; are all (the mapper, entity, dto and value object) in the same nullability context? The related issues you listed were for types for which Mapperly couldn't generate an automatic mapping implementation at the time, but these are not related to nullability.

[latonz]

Closing as no update is received, feel free to reopen...

[pawel-pajak-espeo]

Here we have a minimal reproduction repo. What is worth noting, removing "ProjectToDto" method makes it all work alright, so the problem must be related to the IQueryable.
Also, worth noting, making the InnerRecord in the DTO nullable, also "fixes" the problem.
public record Dto(int Id, InnerRecord? InnerRecord);

https://github.com/pawel-pajak-espeo/MapperlyNullableProblemMinimalSetup

[arkchor]

@latonz Can you reopen the issue? @pawel-pajak-espeo cooperates with me regarding this problem because we're working in the same codebase where the problem was discovered.

[TimothyMakkison]

Thanks for the repo 👍 Looks like the error InnerRecord has no accessible parameterless constructor. is produced.

Not sure why this happens, especially when the generated code looks fine, here's my guess:

In IQueryable mappings, Mapperly assumes that the source values are potentially nullable. So in our case Entity.InnerRecord is assumed to have the type InnerRecord?.
As the constructor for Dto accepts a non nullable InnerRecord Mapperly will attempt to generate the following code to handle the potential null ness of InnerRecord.

return System.Linq.Queryable.Select(form, x => new Dto(x.InnerRecord ?? new InnerRecord()));

As InnerRecord does not have a parameterless constructor Mapperly settles on passing the potentially null value into the constructor and emits a warning message.

The non Queryable mapping doesn't treat source values as nullable so it doesn't have this issue. Equally making Dto accept a nullable InnerRecord removes the need to check the source value for null ness.

I'm not sure if this is a bug or expected behaviour.

[arkchor]

@TimothyMakkison that makes sense. For me it seems like bug. How can I reopen this issue?

[TimothyMakkison]

@TimothyMakkison that makes sense. For me it seems like bug.

Yeah, It feels super unintuitive.

How can I reopen this issue?

I think dont think github lets people reopen issues. You'll have to wait for @latonz or one of the Riok guys to reopen this.

There are more issues related with this (see below) and also I wasn't able to generate mappings for common stuff like IReadOnlyList, IReadOnlyDictionary with same no accessible parameterless

Thanks for mentioning this, it has the same cause but I think it can be fixed. I'll look into adding a special case where new List<T> etc is emitted.

[latonz]

Thanks for the repro, the bugfix is on the way and should land in the upcoming next release.

[latonz]

@TimothyMakkison You mention a problem with `List', I couldn't find anything about it. Can you elaborate on what the problem is? If you have the time, I'd also appreciate a review on the PR 😊

[TimothyMakkison]

@TimothyMakkison You mention a problem with `List', I couldn't find anything about it. Can you elaborate on what the problem is? If you have the time,

Iirc something like the following would emit a parameterless constructor error.

public record Source(List<string> Values);
public record Target(IList<string> Values);

....
public static partial IQueryable<Target>Map(IQueryable<Source> src);

It would work fine with List as the target as it has an accessible constructor. I suspect #1112 fixes it though.

I'd also appreciate a review on the PR 😊

Sure! 😊