Properties with similar names map to undefined

[nrgapple]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the issue

@AutoMap()
  inspection_order_status?: number;

  @AutoMap()
  inspection_order_status_id: number;

 @AutoMap()
  inspectionOrderStatus?: number;

  @AutoMap()
  inspectionOrderStatusId: number;

inspectionOrderStatusId will be undefined in these maps

namingConventions({
          source: new SnakeCaseNamingConvention(),
          destination: new CamelCaseNamingConvention(),
        })

Models/DTOs/VMs

No response

Mapping configuration

No response

Steps to reproduce

No response

Expected behavior

the values should map to their correct values

Screenshots

No response

Minimum reproduction code

No response

Package

• [ ] I don't know.
• [X] code>@automapper/core</code
• [X] code>@automapper/classes</code
• [X] code>@automapper/nestjs</code
• [ ] code>@automapper/pojos</code
• [ ] code>@automapper/mikro</code
• [ ] code>@automapper/sequelize</code
• [ ] Other (see below)

Other package and its version

No response

AutoMapper version

8.7.7

Additional context

No response

[nartc]

Thanks for reporting. The naming convention algorithm isn't smart enough to determine whether

• inspection_order_status_id is inspection_order_status_id
• inspection_order_status_id is inspection_order_status.id

when there is inspection_order_status in the object.

The workaround is to use forMember() on inspection_order_status_id. And please feel free to send a PR to fix the algorithm on this (packages/core/src/lib/utils/get-path.ts)

[vbrzezina]

Hello, as this was a blocker on my current project I decided to dig into it a little and found out the issue is in the flattening algorithm, where the shared suffix is being searched in source object, however, and that is my solution to the problem, it's not checked whether it's actually object and thus needs to be flattened. In the reference source object, primitive values are all undefined, but when there's nested objects, they're expanded as objects with their own properties. So this fix verifies, that the property to be flattened is an object.

I'm honestly wasn't sure if I should add it only at the two places I did or to just add it to the hasProperty function. I also didn't find any existing spec for getFlatteningPaths and as I'm not familiar with it in depth and don't know all the requirements, I'm not sure I'm up to writing all the other test cases..