What is HotChocolate.Data.AutoMapper?

[michaelmcneilnet]

Hello,

We use AutoMapper in our HotChocolate server by injecting IMapper into our resolvers and using ProjectTo<TDest>(_mapper.ConfigurationProvider) against EF Core IQueryables, which is working well for us.

I came across https://www.nuget.org/packages/HotChocolate.Data.AutoMapper/ by chance, but I can't find any documentation on what the package does and whether we should be using it?

[Tim-Maes]

Seems like there is no public repo for this yet. According to the NuGet package explorer it's basically common extensions for AutoMapper and IQueryable.

Example member from the package xml:

<member name="M:HotChocolate.Data.AutoMapperQueryableExtensions.ProjectTo``2(System.Linq.IQueryable{``0},HotChocolate.Resolvers.IResolverContext)">
            <summary>
            Extension method to project from a queryable using the <see cref="T:HotChocolate.Resolvers.IResolverContext"/>
            to project <typeparamref name="TSource"/> into <typeparamref name="TResult"/> based on
            the GraphQL selection.
            </summary>
            <param name="queryable">The Queryable that holds the selection</param>
            <param name="context">The resolver context of the resolver</param>
            <typeparam name="TSource">The source type</typeparam>
            <typeparam name="TResult">The result type</typeparam>
            <returns>The projected queryable</returns>
        </member>

[michaelmcneilnet]

The public repo is at https://github.com/ChilliCream/graphql-platform/blob/main/src/HotChocolate/Data/src/AutoMapper/AutoMapperQueryableExtensions.cs but I don't know if/why we should use these extensions when using AutoMapper.

[JohnGalt1717]

The reason you'd use this is because of the select before where problem. Basically, if you're using DTOs and not your actual database mappings (you should be) then the only way that EF Core can match your query is by projecting into (i.e. select) and then doing the filtering on that projection.

This can cause row locks and also can break indexes in lots of cases.

AutoMapper is relatively unique in that it has .AsDataSource() which allows you to have it use the mappings for your tables and the dto and reverse that to map the where on the DTO to the where on the table so that you get where then select (i.e. where then ProjectTo)

This prevents the row locking issue and the indexes that won't run thus killing perf. If you're using Automapper and not using AsDataSource() in other scenarios for this use case, you should be. It's possibly the most under documented and under appreciated part of AutoMapper.

Basically what that method is doing is AsDataSource() behind the scenes but they've ripped it out so that it can do it in the right spot in the graphQL pipline.

[jamespAWH]

Can you give an example of this select before where problem? What would the graphQL query look like that would trigger this, and what would the raw SQL look like in a query which had this issue?

The reason I am asking is because I am looking at the outputs of my queries using ProjectTo directly from automapper, rather than using the HotChocolate extension method, similar to OP. Yet, I cannot see an example of this problem you mention. But I might not be replicating the right scenario.

Would be happy to use this extension instead if it is the right thing to do but I also don't want to blindly apply it when it appears to not make a difference.

[JohnGalt1717]

Simple case:

Dto has FullName property which is concatenated in the select as FirstName + " " + LastName

This will defeat any indexing on the where clause and cause perf issues that won't be detectable without massive work.

Any aggregation functions etc.

When this is done right, it will error at compile time and tell you that you're causing yourself problems because it can't reverse map the where to the Data object from the DTO.