Note I'm not really updating this anymore. Please see my new iteration of this Ensync.
This is a library for generating and executing SQL diff merge scripts. There are two use cases:
Generate diff script by comparing an assembly or database with another database using DataModel.Compare. This functionality powers my ModelSync app, which is itself open source: ModelSync.WinForms.
Create empty tables from C# model classes with DataModel.CreateTablesAsync.
Nuget package: AO.ModelSync.Library
Use DataModel.Compare
to generate a diff script from an assembly or database to another database. This example is adapted from this test:
using (var cn = GetConnection())
{
var sourceModel = DataModel.FromAssembly(@"c:\users\adam\repos\whatever.dll");
var destModel = await DataModel.FromSqlServerAsync(cn);
var diff = DataModel.Compare(sourceModel, destModel);
string script = new SqlServerDialect().FormatScript(diff);
Debug.Print(script);
}
Output might look like:
ALTER TABLE [child1] DROP CONSTRAINT [FK_child1_parentId]
GO
ALTER TABLE [child2] DROP CONSTRAINT [FK_child2_parentId]
GO
DROP TABLE [parent]
Source links: DataModel.FromAssembly, DataModel.FromSqlServerAsync
Use DataModel.CreateTablesAsync
to create empty tables as part of a component initialization. For example in my WorkTracker project, I create tables from a couple model classes Job and Error. This CreateTableAsync
overload accepts a Func<IDbConnection>
through which your database connection is opened.
await DataModel.CreateTablesAsync(new[]
{
typeof(Job),
typeof(Error)
}, GetConnection);
I have another example along these lines in my Dapper.CX Change Tracking stuff, which creates a couple tables from some model classes.
This is a reboot of my SchemaSync project, which had run into issues I couldn't figure out.
The intent is the same: compare data models to generate a SQL diff merge script. The difference from other database diff apps out there is that this can treat .NET assemblies as data sources -- so that you can merge from C# model classes as well as to and from SQL Server databases. This enables you to use a single tool to migrate model changes end-to-end in your application.
The ultimate goal is to provide a GUI app for use as a Visual Studio "external tool" as an alternative to Entity Framework migrations. I never made peace with EF migrations, and have dabbled in alternative approaches for a long time. I believe it's a better dev experience to merge model classes on demand with a GUI tool rather than interrupting flow to write migrations. Besides being an interruption, migrations have their own administrative complications that, like I say, I never found acceptable.
That said, my approach to model sync works best with a shared development database rather than local database copies. This is because the diff scripting is not always perfect, so a little bit of manual intervention may be needed sometimes. By merging to a shared dev database, you minimize the "finesse" needed to accomplish some merges.
Things different this time around:
The forthcoming GUI tool will be closed-source, but the library that powers it, this repo, will remain open source.