Feature Request: Ability to Commit only Schema Changes

[SteffenBlake]

Challenge

In software development, it's common for software developers to run a local copy of their databases on their personal machines they can test out schema changes against, to validate the migrations apply successfully and dont brick any existing data.

It's quite common for these local databases to have completely different "test" and/or "sanitized" data on them.

The common workflow is for Developers to test out new schema changes, typically via a Migration script of some form, on their test data, and once satisfied with it they check that migration script in and run it against Dev/Qa/UAT/Prod/Etc, pushing their schema changes live.

Currently, Dolt does not appear to support the ability to distinguish between the Data that has been added to the database (new rows, new columns added to rows, etc), vs the Schema that has been mutated (adding a new column, adding a new table, adding a new FK, adding a new index, etc)

It would be quite useful for a developer to be able to have a flag they can use on dolt add that allows them to only check in their changes to the Schema, while completely ignoring any new data added to their database.

Solution

Add the new flag --schema to the command dolt add

Expected behavior

dolt add --schema will behave almost the same as normal dolt add, but as if the current database has zero rows on all tables, that way no data is checked in and only schema updates are checked in.

[timsehn]

Good feature request. We'll consider and get back to you.

[timsehn]

Both dolt diff on the command line and the dolt_patch() function support the ability to filter to just schema changes. So, one could build a manual workflow to only commit these changes, say by applying schema changes to another branch and committing there.

That said, this feature makes a lot of sense to streamline a workflow where you only wanted to persist schema changes only.

As discussed on Discord, I'm a bit worried about the edges cases, like adding a column but I think it would be fine to just stage the default values of those columns if rows exist.