[isuckatcoding]

Ok hear me out. What if this whole process was statefully managed for you as an add on to your database?

Like you essentially defined the steps in a temporal like workflow and then it does all the work of expanding, verifying and contracting.

[Fripplebubby]

I'm hearing you out, but how is this going to affect the part of this that is client behavior rather than database behavior? If there is some kind of sdk that actually captures the interface here (that is, that the client needs to be compatible with both versions of the schema at once for a while) and pushes that back to the client, that could be interesting, like a way to define that column "name" and columns "first name", "last name" are conceptually part of the same thing and that the client code paths must provide handling for both at once.

[marcosdumay]

If you solve that "verifying" step, you will already revolutionize software development.

[nightpool]

On the Rails side, Gitlab has an extensive set of helpers for this that a lot of Rails projects have adopted—I would love to see them pulled out into a Gem or adopted into Rails core proper: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gi...

[vvern]

It should be this way. Clients should have some protocol to communicate the schema they expect to the database probably with some versioning scheme. The database should be able to serve multiple mutually compatible views over the schema (stay robust to column renames for example). The database should manage and prevent the destruction of in use views of that schema. After an old view has been made incompatible, old clients needing that view should be locked out.

[8note]

> The database should manage and prevent the destruction of in use views of that schema. After an old view has been made incompatible, old clients needing that view should be locked out.

this is the interesting part where the article's prpcess matters. how do you make incompatible changes without breaking clients?