Question: Why the changed defaults in v9?

[Ergamon]

I spend hours hunting the "nullable" problem if 7.4.0.

I solved it for now by upgrading to the 9.0.0-pre01.

Sadly this broke my code as the defaults are now different.

Is there any reason for this?

I could make it work again by writing the following code:

    TypeAdapterConfig.GlobalSettings.Default
      .NameMatchingStrategy(NameMatchingStrategy.IgnoreCase)
      .MapToConstructor(true);

So I am curious whats the reasoning behind this change?

And if you dont want to revert back to the old defaults, can there be an easier system to change these defaults?

Having to find a central place for this in every project and every unit test project feels painful.

I would suggest to have some kind of AssemblyAttributes for these configurations, this would allow to set them centrally in Directory.Build.props

[DocSvartz]

@Ergamon Can you provide an example that broke ?
The most accurate description of the Destination type is needed.

[Ergamon]

Sure.

Here is the most simple example I could come up with.

Just create a new ConsoleApp with this:

using Mapster;

var source = new Source
{
  Value = "Test",
};

var target = source.Adapt<Target>();

Console.WriteLine(target.Value);

public class Source
{
  public required string Value { get; init; }
}

public class Target
{
  public Target(string value)
  {
    Value = value; 
  }

  public string Value { get;  }
}

It runs with 7.4.0 with the desired result.

It fails with 9.0.0-pre1.

As written before, it can be fixed to work again, but for my opinion it is really a hard breaking change.

[DocSvartz]

I spend hours hunting the "nullable" problem if 7.4.0.

Was this related to types with such a signature?

Yes, it is breaking changes, record types with this signature are no longer supported.
This caused many unobvious problems, including data "nullification"

• Critical regression introduced in Mapster 7.3.0 when mapping to existing objects #537

using C# Records or data annotation if you want to keep the behavior [AdaptWith(AdaptDirectives.DestinationAsRecord)]

[AdaptWith(AdaptDirectives.DestinationAsRecord)]
public class Target
{
    public Target(string value)
    {
        Value = value;
    }

    public string Value { get; }
}

[Ergamon]

I dont like the attribute approach as this would tie the libraries containing the objects with Mapster.

But as you wrote changing the target type to a record works.

Perhaps I am missing something, but I thought record is just a class with something additional added by the compiler.

But you are right, changing target to this makes the code work again without any changes to the configuration:

public record Target
{
  public Target(string value)
  {
    Value = value; 
  }

  public string Value { get; }
}

Still makes me stay away from the newer versions. We have hundreds of libraries in NuGet packages with these types. Most of them quite old before the introduction of records. It is impossible to be sure if the code still works after upgrading

[DocSvartz]

Perhaps I am missing something, but I thought record is just a class with something additional added by the compiler.

Yes, but its main difference is that it is immutable by Design and additional added by the compiler allows to clearly target it while avoiding the side effects mentioned in the issues.

[DocSvartz]

I think could be added Auto-activation for classes with a single constructor with parameters.
But there is a problem with the data requirement for constructor parameters.

It has been activated default value for type or throw Exception if Source not member matching by name

[DocSvartz]

I think could be added Auto-activation for classes with a single constructor with parameters.

It looks like there's a problem there. It should probably be up to the user to decide which classes should be processed this way.

You also can use the following workaround using .ForDestinationType()

 var source = new Source
 {
     ValueX = "Test",
 };


//// custom type filter
var types = Assembly.GetExecutingAssembly().GetTypes()
             .Where(t => t.IsClass)
             .Where(t=> !t.GetInterfaces().Any(i => i == typeof(IEnumerable)))
             .Where(t=> t.GetConstructors().Count() == 1
             && t.GetConstructors().Any(p=>p.GetParameters().Count()  != 0));

  foreach (var item in types)
  {
      TypeAdapterConfig.GlobalSettings
      .ForDestinationType(item)
      .NameMatchingStrategy(NameMatchingStrategy.IgnoreCase)
      .MapToConstructor(true);
  }
/////

TypeAdapterConfig<Source, Target>
    .NewConfig()
    .Map(dest => dest.Value, Src => Src.ValueX);



var target = source.Adapt<Target>();

[DocSvartz]

@andrerav @stagep @DevTKSS
If everyone agrees, this can be added in the following form. This will work for the following cases:

1. The Destination Type must not have a default constructor.
2. If a constructor cannot be assembled from the Source Type members, an error will be thrown indicating manual mapping is required.

class destX
{
    public destX (int z)
    {
       X = z;
    }

    public int X { get;}
}

/////////////////////////////////////
public void NotWokingCase()
{

    var _source = new TestRecord() { X = 700 };

    var result = _source.Adapt<destX>(); // exeption
}

////////////////////////////////////////////
public void WokingCase()
{

    TypeAdapterConfig<TestRecord, destX>
         .NewConfig()
         .Map("z", source=>source.X);

    var _source = new TestRecord() { X = 700 }; 

    var result = _source.Adapt<destX>();  // result.X = 700
}

[DevTKSS]

Hey @DocSvartz,
I totally can understand and appreciate the feature with immutability and records, but I indeed would want to agree with @Ergamon if it would be me who had to do the changes on all the libraries. 😅

What I would expect & suggest:

1. Existing Mappings must not fail and by that break existing code, which might be still use regular classes or even records without primary ctor usage, just because because we introduced a new Feature.

2. Instead, we should target to instead introduce this as real Feature. Those are the realistic Options I see for this:
   A) Smallest change Option:

   1. Revert the Options Default Value change (but keep the Method name as-is) just like it seems to be required with Mapster.Tool

   2. Require Users, who want to opt-in to this Feature. Considerable Ways to do this:

      1. Require adding this in the Fluent Builder for TypeAdapterConfig just as we now seem to require from Upgraders

      Since 1 might require additional code when avoidable, maybe we could check this ones too:

      2. (IHostBuilder).UseMapsterMapping() With those signature Options:
         1. (Default) .UseMapsterMapping(TypeAdapterSetter settings = TypeAdapterConfig.GlobalSettings.Default)
         2. Manual config overload without appsettings: .UseMapsterMapping(Func<TypeAdapterConfig,TypeAdapterSetter> configure)
         3. appsettings*.json usage: .UseMapsterMapping(string sectionName = "MapsterConfig", Func<IHostBuilderContext,IConfigurationSection> configure = null)
            B) maybe we can check the Idea with the Attribute he suggested, as alternative way for Settings
            C) csproj tag based settings?
            D) provide a new Method name if you really want to keep the Config Default Change, so this Feature can be used from those who want Record support and but not break existing code 🤔

But I never looked into reading Attributes or csproj tags at runtime, so I would not be a big help for this.

While we are in Prerelease versioning of this Breaking Changes, we can adjust and try to keep the required User actions smallest possible while still providing the Feature enhancement, which would in my opinion the best outcome we should want to target.

@DocSvartz By the way, did you recognize the current tests are also showng failures on those parts he mentioned?

[DocSvartz]

Hi @DevTKSS. The main problem is that this isn't an improved feature.

If you read the Wiki carefully, you'll see the following:

1. All types are "Activated constructor" using an empty constructor.
2. "Activating constructor" with default type values ​​is not supported for types, based on point 1.
3. Only Mapster record types could be "activated constructor" with parameters without using manual mapping settings.
   3.1) However, both the signature and actual behavior during mapping treated the Mapster record type as an immutable entity.

All of this has remained unchanged except that is now considered a record type.

The initial problems were as follows:

1. Users didn't understand that Mapster record types were immutable.
2. MapToTarget didn't actually work for Mapster record types, because immutable types actually required a different processing pipeline.

Currently, the behavior of the other types remains unchanged.
The following improvements have been added to the Record type:

1. "Activating constructor" with default type values.
2. MapToTarget case using "with like" Nondestructive mutation

[DocSvartz]

Adding automatic activation of mutable types is a simple task.
I've already done it here:

• Add class with custom Ctor AutoMapping by default #844

But now again, the following problems arise:

1. "Activating constructor" with default type values
   Now Current behavior requires manual configuration

2. MapToTarget should be different for such cases.
   It will differ from both the current behavior and the cases for immutable types.

[DocSvartz]

@DevTKSS

I would suggest to have some kind of AssemblyAttributes for these configurations, this would allow to set them centrally in Directory.Build.props

As far as I understand, all configuration for mappers is currently created at runtime (this is, by the way, the reason why it's not so easy to do sourcegenerator 😅)

 TypeAdapterConfig<TestRecordY, TestRecordY>
     .NewConfig()
     .Ignore(dest => dest.Y);

line 5:  -->  only after the program execution reaches this line, the configuration for this types will be created

B) maybe we can check the Idea with the Attribute he suggested, as alternative way for Settings

I think this can only be done using a settings file, mapster-setting.json.
Which will be read when the program starts. 🤔