[linkdd]

Thank you for your clarification.

I like to think about a single migration being a function and a migration history multiple functions being composed.

Category theory's main subject (I think) is composition and a lot of good ideas can be taken from there (see this paper: "Functorial Data Migration"[1]).

There is an obvious relationship between a schema and the data, and a migration operates on both. The schema might be versioned, but unless you use a Schema-less database (ie: MongoDB) and handle the data versioning application side, your data is not.

Any document/graph-based database can avoid this problem by assigning a version to your documents (like apiVersion+kind in Kubernetes), then the application should know how to process each version of the data.

In an SQL database, it would require different tables which complexify the data model.

IMHO, in every case, you need to handle some of the logic application side or maintain an history of your data (bye-bye storage space?).

[1] - http://math.mit.edu/~dspivak/informatics/CD-FDM.pdf

[tomhoule]

Ooh it's interesting you mention David Spivak's work, I got interested into it recently. Some of these ideas are being commercialized by https://conexus.com/ (he's a co-founder). You might also be interested by Project Cambria[1] for novel ideas about data and schema migrations based on lenses.

We haven't gone in the fancy direction yet, because we wanted to first have the tool our users told us they were missing - namely a migration tool similar to what other ORMs have, but playing on the strengths of the Prisma schema. But these novel ideas about migrations are definitely something we always read with a lot of interest and love to discuss — I hope we get to implement something radical like that some day.

[1]: https://www.inkandswitch.com/cambria.html