Properties that contain capitalized abbreviations cannot also be mapped in the fluent API when mapping to a record

[CerebralUnit]

There are several properties in the Adverse record on the domain model that have abbreviations and are therefore capitalized (e.g. HDMAReasons.) Regardless of the naming strategy Exact, IgnoreCase, Flexible etc.. Mapster will fail execute a custom mapping unless a Pascal case version of the property is passed in for the destination object. Using x => x.HDMAReasons causes the mapper to throw a configuration error saying that there is neither a mapping nor an Ignore for HdmaReasons. Neither object being mapped has that casing. Example of the code that finally worked below.

config.MapDependentTo<Adverse, Domain.Adverse>()
.MapToConstructor(true)
.NameMatchingStrategy(NameMatchingStrategy.IgnoreCase)
.Map("HmdaReasons", src => src.HMDAReasons.Select(x => x.EnumValue))

[andrerav]

Might be related to #388.

[JMPSequeira]

@CerebralUnit could you provide the models used for the issue? And please clarify if the specific problem only occurs when mapping to a constructor.

[ventii]

Had the exact same issue - fields with consecutive capital letters in a C# record constructor are not mapped even when the source record/class has the same field with the same name.

non working example:

public record MySourceRecord(DateTime ValidFromUTC);

public record MyDestinationRecord(DateTime ValidFromUTC);

// having the following config
config.NewConfig<MySourceRecord, MyDestinationRecord>();

got it to work by doing the following changes:

// change property name of destination record to PascalCase
public record MyDestinationRecord(DateTime ValidFromUtc);

// update config to specify mapping

config.NewConfig<MySourceRecord, MyDestinationRecord>()
                .Map(dest => dest.ValidFromUtc, src => src.ValidFromUTC);

I was going crazy as I initially thought it was some bug with DateTime.

Is this a known issue please?

[andrerav]

@ventii Yes this is a known issue, the name matching strategy does not seem to be working as intended.

[andrerav]

See also #388.