Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inheritance and scanning assembly for IRegister. #726

Open
vchc opened this issue Sep 4, 2024 · 2 comments
Open

Inheritance and scanning assembly for IRegister. #726

vchc opened this issue Sep 4, 2024 · 2 comments

Comments

@vchc
Copy link

vchc commented Sep 4, 2024

If you use IRegister to define the inheritance mapping like this:

DerivedPocoProfile.cs

public class DerivedPocoProfile : IRegister
{
    public void Register(TypeAdapterConfig config)
    {
        .NewConfig<DerivedPoco, DerivedDto>()
        .Inherits<SimplePoco, SimpleDto>();
    }
}

SimplePocoProfile.cs

public class SimplePocoProfile : IRegister
{
    public void Register(TypeAdapterConfig config)
    {
        .NewConfig<SimplePoco, SimpleDto>();
    }
}

and then use scan assembly for types:

TypeAdapterConfig.GlobalSettings.Scan(typeof(DerivedPocoProfile).Assembly);

there is no guarantee that the base type will be registered first and

.Inherits<SimplePoco, SimpleDto>();

will fail silently, leaving your mapping inconsistent.

The current implementation of Inherits does nothing and simply returns when the type tuple has not yet been registered.

@praschl
Copy link

praschl commented Nov 18, 2024

Same problem here. Our current fix is to do all that manually, so we can guarantee a specific order of registration, but that is still error prone, and would be so much better if Inherits<,> would evaluate lazily.

Edit: we do not use TypeAdapterConfig.GlobalSettings.Scan - but have our own interface & scanner, so it's not a problem with TypeAdapterConfig.GlobalSettings.Scan

@vchc
Copy link
Author

vchc commented Nov 18, 2024

Edit: we do not use TypeAdapterConfig.GlobalSettings.Scan - but have our own interface & scanner, so it's not a problem with TypeAdapterConfig.GlobalSettings.Scan

I came with the same solution for the problem - to reorder registrations manually.

And I think any assumptions on the library's part about the order or location of IRegister implementations may turn out to be wrong. So there is no simple way to handle this problem lazily.

There can be three ways to the universal solution:

  1. To chain registrations. Like
    .Inherits<DTOEntity, Entity>().WithRegistration(IRegister)
    which is somehow cumbersome.
  2. To use a new typed IRegister interface and to rewrite the scanner and handle the order of registrations with taking into account the inheritance hierarchy of the registering types.
  3. To handle registration in two steps. Collect all Configs for types. Execute them in reordered sequence based on the inheritance hierarchy. Something like this:
    DefaultConfig.Collect(First Assembly)
    DefaultConfig.Collect(Second Assembly)
    ...
    DefaultConfig.Register()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants