dradovic / MigSharp

Mig# (MigSharp) is a .NET framework for database migrations and versioning
Other
106 stars 34 forks source link

Migration version number #36

Closed nicholassuter closed 11 years ago

nicholassuter commented 12 years ago

At the moment, the migration version number is calculated based on the class name. Wouldn't it be cleaner if it were an attribute of the MigrationExport class ? Something like :

[MigrationExport(Version=1, ModuleName = "myModule", Tag = "myTag")]
public class myMigration : IReversibleMigration
{
     [...]
}

And rather than a long, version could be any type implementing IComparable and IComparer, being stored as a string in the database version table.

dradovic commented 12 years ago

It is encoded in the class name because typically you would have many migration in the same namespace/folder which forces you to have distinct filenames. So most probably your filename/classname will already contain the timestamp. Then, adhereing to the DRY principle you only one to specify it at one place.

If you allow any IComparable, how to you know how to serialize into a string then? And do you have a specific concern about using 'long'?

nicholassuter commented 12 years ago

Thanks for the fast answering.

My main concern was that my software follows the standard version naming (ex : v1.0, v1.2b4, v1.2.1...). And here, I must map my application version to the migration version. I just think String is more convenient and open that Long. And since ToString() belongs to System.Object, everything is "stringable". Besides, Mig# must already cast the classname suffix from String to Long anyway.

Besides that, I understand your argument on the class naming. With Fluent Migrator, I was using the same timestamp in my classname and in the Migration attribute.

dradovic commented 12 years ago

Ok, you "serialize" an IComparable by calling ToString. How do you deserialize it then?

Why do you need to map the application version to a migration timestamp? Isn't your software just upgrading the database to the latest version?

Let's assume the version number is simply a string instead of a long and we are using alphabetical order. Then you would have migration timestamps like 1.2b4.099, 1.2b4.0100, 1.2b4.0101, etc.? Or do you have only one big migration per application version? How do you upgrade a database from a v1.1 branch to v2.0? Are migrations being shared between the release branches? Or are they replayed? Many questions. Properly handling multiple application versions can be tricky.