We had a problem in the project where migrations without the MigrationAttribute were throwing an unhelpful exception. This was fixed with commit a5303d38736868e88f7cf6fe26ed471ce8722db1. However, this fix technically changes the public API in that migrations that would previously throw will now just be skipped. One of the reasons this fix is useful is that it allows having a base class for your migrations that don't have the attribute.
An alternative approach that I'm proposing would be to throw a more helpful exception when there is a migration missing the attribute. In addition, we could maintain the base class support by adding code to filter out things that inherit from Migration that cannot be instantiated. So, for example, if you wanted to have a base class for a set of similar migrations, your base class should be an abstract class, which would be skipped because it can't be instantiate. The subclasses would have the attribute and would actually be picked up by the runner.
I know this seems like a small thing, but it would help us avoid a technically breaking change, and also give more meaningful feedback when migrations without attributes are added.
dportzline83
commented
9 years ago
We had a problem in the project where migrations without the
MigrationAttributewere throwing an unhelpful exception. This was fixed with commit a5303d38736868e88f7cf6fe26ed471ce8722db1. However, this fix technically changes the public API in that migrations that would previously throw will now just be skipped. One of the reasons this fix is useful is that it allows having a base class for your migrations that don't have the attribute.An alternative approach that I'm proposing would be to throw a more helpful exception when there is a migration missing the attribute. In addition, we could maintain the base class support by adding code to filter out things that inherit from
Migrationthat cannot be instantiated. So, for example, if you wanted to have a base class for a set of similar migrations, your base class should be an abstract class, which would be skipped because it can't be instantiate. The subclasses would have the attribute and would actually be picked up by the runner.I know this seems like a small thing, but it would help us avoid a technically breaking change, and also give more meaningful feedback when migrations without attributes are added.