Synnotech.Migrations

A lightweight generic migration engine for .NET

When starting a new project, do you always spent too much time on how you can migrate your database? Do you want a migration mechanism that is independent of any persistence technology, like ORMs for relational databases? Worry no more because Synnotech.Migrations offers just that! Our generic migration engine is written in such a way so that you can easily adapt it to your own data access layer, no matter the technology: relational databases with and without ORMs, document or graph databases, the file system, or web services - the possibilities are endless.

Synnotech.Migrations also offers integration packages that get you started quickly:

Raven DB
Linq2Db
Entity Framework Core to be completed
Entity Framework

Please visit the corresponding pages for further documentation.

Our Philosophy for Migrations

The dev is in control: Synnotech.Migrations is unobtrusive, it does not care about the internal structure of your migrations. We recommend choosing the best tools to manipulate your target system, e.g. TSQL for MS SQL Server, PL/SQL for Oracle, RQL or the RavenDB.Client for Raven DB, HTTP calls for a web service. Simply execute the code you want within your migrations.
We don't look back: Migrations should not have a Down method to reverse it. Not only does this extend the time you need to implement a migration, but it also might lead to data loss, e.g. when a column or table is dropped that was previously added. If one of your migrations is erroneous, write a new one that fixes it.
No addtional CLI tools: Synnotech.Migrations offers you an API that you can directly call within your apps. You don't need additional tools for the command line.

Supported Frameworks

Synnotech.Migrations is build for .NET Standard 2.0 and .NET Standard 2.1, so you can use it on all platforms that support it, e.g. like:

.NET 5 or newer
.NET Core 2.0 or newer
.NET Framework 4.6.1 or newer
Mono 4.6 or newer
Unity 2018.1

Contributions Are Welcome

If you have questions or have an idea for a new feature, please create an issue.

TODO: we need to create contributing guidelines

Latest MigrationInfo is incorrect if all previous migrations have the same AppliedAt time stamp

Description

PR #8 solved #7 by correctly querying the most recently applied MigrationInfo in descending order:

var migrationInfos = await DataConnection.GetTable<TMigrationInfo>()
                                         .OrderByDescending(migrationInfo => migrationInfo.AppliedAt)
                                         .Take(Take)
                                         .ToListAsync(cancellationToken);
return migrationInfos.GetLatestMigrationInfo();

Unfortunately an incorrect migration is still returned in the following scenario:

There are more than Take migrations (defaults to 100)
All migrations are applied onto an empty database in a single run of MigrationEnginge.MigrateAsync(). All of the corresponding MigrationInfos are assigned the same time stamp
During the next run of the MigrationEngine it is up to the database engine to determine the order as the AppliedAt values of all MigrationInfos are equal. In the case of MSSQL Server the first Take migrations are returned, not the last. Consequently, migration #Take is incorrectly identified as the last one and the engine tries to reapply the remaining migrations starting from Take + 1.

Possible Workarounds

Use different timestamps for every pending migration. This does not solve the problem for existing databases, though.
Order by the AppliedAt AND the Id column. This workaround depends on the ID generation for the MigrationInfos table.

synnotech-ag / synnotech.migrations Goto Github PK