Data Commits
A commit is a set of data changes applied to a table as one act.
Most of the time you never think about it. A table edits automatically: you change a cell, and the change lands. Everyone else working in the model sees it immediately, and it becomes a new table version.
Sometimes that is not what you want. If you are reworking twenty cells and the result is only correct once all twenty are done, you do not want collaborators reading the half-finished state. For that, a table can be paused, and the changes gathered into a commit you apply yourself.
Automatic and manual
| Automatic | Manual | |
|---|---|---|
| When changes land | As you make them | When you apply the commit |
| What others see meanwhile | Every change, at once | Nothing until you apply |
| How to undo | Undo, or edit again | Discard the commit |
A control on the table switches between the two. While a table is paused, your edits accumulate instead of landing, and the table shows that a commit is open.
Two things you can then do:
- Apply the commit. Every change lands together and becomes one new table version.
- Cancel the commit. Every staged change is dropped and the table returns to where it was.
While a commit is open
Columns cannot be changed. Adding, removing or retyping a column during an open commit is refused — "Cannot modify columns during active commit" — because the staged changes are described against the columns as they stand.
Nobody else sees the staged work. That is the point of pausing.
Conflicts
If someone else changes the same data while your commit is open, the commit is marked as conflicted. It cannot be applied as it stands, because doing so would silently overwrite work you never saw.
Resolve it by dropping the commit and redoing the edits against the current state.
Conflicts are the cost of holding changes back. An automatic table cannot conflict, because each change lands against the state that existed a moment before it.
Where commits do not apply
Imported tables cannot be committed, and show no commit control at all. An imported table is a view onto a table owned by another model; it is read-only where it sits, and editing happens in the model that owns it.
See Sharing Tables for how an imported table relates to its original.
Commits and versions
Applying a commit produces exactly one new table version, however many cells it touched. That is worth knowing if you are working through a table's history: a manual commit of twenty edits is one entry, while the same twenty edits made automatically are twenty.
You can pin either with a checkpoint.