{"@context":"https://w3id.org/codemeta/3.0","@type":"SoftwareSourceCode","identifier":"pkg:hackage/migrant-core","name":"migrant-core","description":"\n\n[Index] [Quick Jump]\n\nPackage maintainers\n\nFor package maintainers and hackage trustees\n\nCandidates\n\n\n\nOpinionated SQL schema migration management\n\nMigrant instruments SQL schema migrations in a semi-automated way. Writing the\nactual up- and downgrade scripts is still a manual effort; but Migrant takes\ncare of tracking which scripts have been run already and which still need to be\nrun, runs them for you.\n\nDatabases are notoriously difficult to version-control.\n\nVersioning source code is a solved problem: we write code, put it in a\nrepository, and the source control software gives us a unique identifier for\nthat exact version. We can now deploy the code in whichever state we want, and\nas long as we keep code and data separated, we can do this in a fairly\nbrute-force manner: we just delete the old code, copy the new code where it\nneeds to be, and restart what needs to be restarted. Easy. And because we can\ndeploy any version of the code we want on any host we want, we can test our\ncode on one machine (a test server), and then deploy it on another (a\nproduction server), and be reasonably sure that if it works on the test\nenvironment, it will also work in production. We can also, just as easily,\nrevert the code to an older version, if one of our changes turns out to have\nintroduced a fault.\n\nBut with SQL databases, this doesn't work. The schema and the data stored in\nthe database are intertwined; we want to manage the schema, but we want to do\nit such that no data is lost. We cannot simply overwrite the schema: if we\ndelete a schema, we also delete all the data in it, because in an SQL database,\ndata cannot exist without the associated schema. Even small changes, such as\nchanging the type of a column, can be destructive, and so there is a real risk\nof permanently losing data as a result of schema changes. And this means we\nmust be more surgical about our database mutations.\n\nThere are two fundamental approaches to this, which I call \"snapshot-based\" and\n\"delta-based\".\n\nThe \"snapshot-based\" approach stores a snapshot of the schema at a given\nversion in the source control system; to migrate the database to that version,\nit looks at the current schema, and infers the schema changes that are required\nto get the schema into the desired state (or a compatible one). For example, if\nthere is a table products in the database that has three columns (id,\nname, price), and the version-controlled schema description says it should\nhave columns id, name, price, image, then the migration code infers\nthat the image column must be added.\n\nThe \"delta-based\" approach, which is what Migrant uses, stores descriptions of\nthe steps required to arrive at the current schema. A migration run, then,\nfigures out which migration steps have already been executed, and which ones\nare needed to get the schema where we want it, and executes the required steps.\nIn our example above, there may be two upgrade steps: create-products-table,\nand add-product-image. The migration code detects that only the\ncreate-products-table step has been run, and decides to run the\nadd-product-image step.\n\nMigrant migrations are implemented using three key parts:\n\nExample:","version":"0.1.1.1","softwareVersion":"0.1.1.1","license":"https://spdx.org/licenses/BSD-3-Clause","codeRepository":"https://github.com/tdammers/migrant","issueTracker":"https://github.com/tdammers/migrant/issues","url":"https://github.com/tdammers/migrant","keywords":["bsd3","database","library","Propose Tags"],"programmingLanguage":{"@type":"ComputerLanguage","name":"Haskell"},"maintainer":[{"@type":"Person","name":"TobiasDammers"}],"author":[{"@type":"Person","name":"TobiasDammers"}],"copyrightHolder":[{"@type":"Person","name":"TobiasDammers"}],"dateCreated":"2020-11-25","dateModified":"2026-01-13","datePublished":"2026-01-13","copyrightYear":2020,"downloadUrl":"https://hackage.haskell.org/package/migrant-core-0.1.1.1/migrant-core-0.1.1.1.tar.gz","applicationCategory":"hackage","runtimePlatform":"hackage","developmentStatus":"active","sameAs":["https://hackage.haskell.org/package/migrant-core"],"https://www.w3.org/ns/activitystreams#likes":8,"https://forgefed.org/ns#forks":3}