Schema Migrations and Patches
TIP
All of the schema migration functionality is surfaced through Marten's command line support and that is the Marten team's recommended approach for using the schema migration functionality described in this page.
While it's going to be far less mechanical work than persisting an application via relational tables, Marten still needs to create matching schema objects in your Postgresql database and you'll need some mechanism for keeping your database schema up to date with the Marten StoreOptions
configuration in your system.
Development Time with "Auto Create" Mode
WARNING
Heads up, all the API methods for invoking schema checks or patches or migrations are now asynchronous as of Marten V4.
As long as you have rights to alter your Postgresql database, you can happily set up Marten in one of the permissive "AutoCreate" modes and not worry about schema changes at all as you happily code new features and change existing document types:
var store = DocumentStore.For(_ =>
{
// Marten will create any new objects that are missing,
// attempt to update tables if it can, but drop and replace
// tables that it cannot patch.
_.AutoCreateSchemaObjects = AutoCreate.All;
// Marten will create any new objects that are missing or
// attempt to update tables if it can. Will *never* drop
// any existing objects, so no data loss
_.AutoCreateSchemaObjects = AutoCreate.CreateOrUpdate;
// Marten will create missing objects on demand, but
// will not change any existing schema objects
_.AutoCreateSchemaObjects = AutoCreate.CreateOnly;
// Marten will not create or update any schema objects
// and throws an exception in the case of a schema object
// not reflecting the Marten configuration
_.AutoCreateSchemaObjects = AutoCreate.None;
});
As long as you're using a permissive auto creation mode (i.e., not None), you should be able to code in your application model and let Marten change your development database as needed behind the scenes to match the active configuration.
Exporting Schema Patches
It's somewhat unlikely that any self-respecting DBA is going to allow your application to have rights to execute schema changes programmatically, so we're stuck needing some kind of migration strategy as we add document types, Javascript transformations, and retrofit indexes. Fortunately, we've got a decent start on doing just that with the IDocumentStore.Schema.WritePatch(string file)
command that will dump a SQL file with all the Data Definition Language (DDL) commands necessary to bring a database schema into alignment with the current Marten configuration.
In usage, you would need to tell Marten about every possible document type, any event store usage, and any javascript transforms so that Marten "knows" how to make the full comparison:
var store = DocumentStore.For(_ =>
{
// This is enough to tell Marten that the User
// document is persisted and needs schema objects
_.Schema.For<User>();
// Lets Marten know that the event store is active
_.Events.AddEventType(typeof(MembersJoined));
});
Then to write a patch DDL file, bootstrap your IDocumentStore
pointing to the database connection you want to update, and use:
await store.Schema.WriteMigrationFileAsync("1.initial.sql");
The command above will generate a file called "1.initial.sql" to update the schema, and a second file called "1.initial.drop.sql" that attempts to rollback all of the changes from "1.initial.sql." Today, the WritePatch()
mechanism covers:
- Creates any missing database schemas
- Document storage tables, "upsert" functions, and any configured indexes
- Javascript transforms
- The Hilo support table
- The Event Store schema objects
Apply All Outstanding Changes Upfront
To programmatically apply all detectable schema changes upfront when an application is first bootstrapped, you can use this mechanism:
await store.Schema.ApplyAllConfiguredChangesToDatabaseAsync();
Assert that a Schema Matches the Configuration
As a possible environment test, Marten can do a complete check of its known configuration versus the active Postgresql database and assert any differences by throwing an exception:
await store.Schema.AssertDatabaseMatchesConfigurationAsync();
The exception will list out all the DDL changes that are missing.