Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • castellum castellum
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2
    • Issues 2
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • CastellumCastellum
  • castellumcastellum
  • Merge requests
  • !1503

Squash migrations

  • Review changes

  • Download
  • Email patches
  • Plain diff
Closed Bengfort requested to merge squash-migrations into main Sep 01, 2020
  • Overview 2
  • Commits 5
  • Pipelines 1
  • Changes 50

I wanted to learn about squashmigrations so this is an example on how we could use it.

Migrations are no longer relevant once they have been executed, so they are basically a bunch of dead code. Migrations can also get quite complex on larger refactoring. Getting rid of dead complex code seems like a good idea.

On the other hand, this breaks installations that have not executed these old migrations. In other words: It makes updating more complicated. And even though it feels strange, keeping those old migrations doesn't actually hurt.

If you checkout this branch and run migrateall it will not work. Instead, you first have to checkout the "squash migrations" commit and run migrateall there. This will store the squashed migrations in the database so that django later knows that they do not need to be executed again.

Theoretically, we could squash all migrations on every release and then cleanup on the next release. But should we? I am torn.

The django docs recommend not to do it:

You are encouraged to make migrations freely and not worry about how many you have

Still I feel like we should cleanup early refactoring before our first "real" release. But maybe not adding migrations at all until !1058 (merged) was already sufficient for that goal.

Edited Sep 01, 2020 by Bengfort
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: squash-migrations