Partial select based on column names about mapperly

[latonz]

Thank you for opening this issue and sponsoring the project!

We are always happy to welcome new contributors and to assist them for their contributions.

If everything works correctly EF should only query the data needed for the DTO. If I understand you correctly, you would additionally want to provide a list of column names as strings, which columns should be queried?
Mapperly has no reference to the EF model and does not know how to map between property and column names. This mapping is the job of EF Core not Mapperly. Can you elaborate on your use-case? Why do you want to have properties present in your DTO which you don‘t want to query?

May also be related to #953 (the mapping generated by Mapperly results in too mich data loaded by EF).

[svrooij]

We would make all the properties in the DTO nullable, and then have the client of the api specify which columns it needs, thus having 1 endpoint that can be used for all client.

// This fictive code would do the job
var posts = context.Posts.Select(p => new PostDto{
  // Using the condition this way, does not work I guess?
  Id = colums.Contains("Id") ? p.Id : null
});

And we are currently using this code (no mapper) that we would like to replace:

private static IQueryable<TDto> ApplySelect<TIn, TDto>(this IQueryable<TIn> query, string? select) where TIn : class, new() where TDto : class, new()
{
    if (!string.IsNullOrWhiteSpace(select))
    {
        var inType = typeof(TIn);
        var dtoType = typeof(TDto);
        var properties = select.Split(',');
        var parameter = Expression.Parameter(inType, "p");
        var newExpression = Expression.New(dtoType);
        var bindings = new List<MemberBinding>();
        foreach (var property in properties)
        {
            var inPropertyInfo = inType.GetProperty(property);
            if (inPropertyInfo == null)
            {
                throw new ArgumentException($"The $select parameter contains a property name '{property}' that does not exist on type '{inType.Name}'.");
            }
            var dtoPropertyInfo = dtoType.GetProperty(property);
            if (dtoPropertyInfo == null)
            {
                throw new ArgumentException($"The $select parameter contains a property name '{property}' that does not exist on type '{dtoType.Name}'.");
            }
            var propertyAccess = Expression.MakeMemberAccess(parameter, inPropertyInfo);
            var binding = Expression.Bind(dtoPropertyInfo, propertyAccess);
            bindings.Add(binding);
        }
        var memberInit = Expression.MemberInit(newExpression, bindings);
        var selectExp = Expression.Lambda<Func<TIn, TDto>>(memberInit, parameter);
        return query.Select(selectExp);
    }
    return query.SelectAll<TIn, TDto>();
}

[latonz]

I see your use-case but I'm afraid this is out of scope of Mapperly.

It is probably not even possible with source generation while not using reflection.
If you can rewrite the code you provided without reflection it is possible using source generation 😉

I'm closing this for now as out of scope.

[svrooij]

Here is the full code that I generated myself without reflection, I'm still hoping this code could also be auto generated.

public static IQueryable<PostDto> SelectDtoColumns(this IQueryable<Post> posts, string[] columns)
{
   return posts.Select(p => new PostDto
   {
      Id = colums.Contains(nameof(Post.Id)) ? p.Id : null,
      Title = colums.Contains(nameof(Post.Title)) ? p.Title : null,
      ....
   }); 
}

[latonz]

Does it work like this? I didn't try it but just from reading the code I'd think EF Core would try to translate the columns.Contains part to SQL too since it is part of the select expression.

[svrooij]

The condition is evaluated before sending to the server. So the resulting SQL (with coulmns = new [] {"Id"} is:

SELECT Id, null as Title FROM Posts .....

So the expression is evaluated before sending to SQL. Which is at least better then selecting the values and then removing them when sending to the client. This way they are not loaded from the database.

[svrooij]

@latonz with these last comments, would it be something that might be accepted in this library? And can you un-close the issue if that is the case?

[latonz]

I don't think this should be included in Mapperly as it seems to be very specific and therefore outside the scope of Mapperly.