Migration type identification error about orchardcore HOT 9 CLOSED

All public types were previously added to the main feature as well, even if they were not in DI or had no attribute. So to keep it compatible, this feature assignment was kept. But I haven't thought enough about the migrations.

from orchardcore.

It looks like we should keep the FeatureAttribute on the migration type of the submodule

from orchardcore.

How is this different to #16223?

from orchardcore.

Do you have an easy way to reproduce the issue?

from orchardcore.

The problem is that the migration manager is not allowing a migration to have more than one feature. But after removing the FeatureAttribute from migrations, they will always be assigned to the main feature of their parent module and afterwards to the more specific feature via DI. So they will have two features if more than one migration is contained in a assembly.

There are two solutions possible:

1. The data migration manager can always just use the last feature for a migration. This will always be the right feature as long as migrations are added to a single startup only. But this will not be obvious for anyone looking at the migration manager and may break if we change something in future.
2. We can introduce a way to force types to be assigned to a single feature only.

I tend to suggest the second option.

from orchardcore.

Just like this ?

public class MyMigration :DataMigration<MyFeatureStartup>

It has the advantage of introducing strong type-checking and not needing to log those strings anymore~

from orchardcore.

That would be the same as applying the FeatureAttribute like before. We wanted to avoid having to do that manually each time. I think we can add something to the base interface IDataMigration.

from orchardcore.

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

from orchardcore.

But after removing the FeatureAttribute from migrations, they will always be assigned to the main feature of their parent module and afterwards to the more specific feature via DI.

Why is that the case? Shouldn't just the second happen?

from orchardcore.