59 lines
3.1 KiB
Plaintext
59 lines
3.1 KiB
Plaintext
--------
|
|
THIS IS THE TEMPLATE MIGRATION FILE FOR NEW MAJOR VERSION OF METABASE
|
|
On each new major version, copy this file to `resources/migrations/###_update_migrations.yaml` where `###` is the major metabase version.
|
|
The file can be empty until migrations need to be added.
|
|
--------
|
|
|
|
databaseChangeLog:
|
|
- objectQuotingStrategy: QUOTE_ALL_OBJECTS
|
|
|
|
# >>>>>>>>>> DO NOT ADD NEW MIGRATIONS BELOW THIS LINE! ADD THEM ABOVE <<<<<<<<<<
|
|
|
|
########################################################################################################################
|
|
#
|
|
# ADVICE:
|
|
#
|
|
# 1) Think through some of these points when writing a migration, learn from our past mistakes:
|
|
# - Do you really need a migration? Could the feature work without it? Prefer not to if possible.
|
|
# Data in the wild can be vastly different from what you expect, and it's hard to get right.
|
|
# - Make sure your migration is backward compatible: it might not be possible to add a constraint back
|
|
# if you drop it in a migration.
|
|
# - Postgres, MySQL and H2 have their differences. Make sure your migration works for all.
|
|
# - Database encryption is a major issue:
|
|
# - Fields like `metabase_database.details` or `setting.value` can be encrypted, so you need to decrypt them in
|
|
# your migration. See #42617, #44048.
|
|
# - Database could be partially encrypted, see https://www.notion.so/72575933ef2a446bafd16909e05a7387
|
|
# - Custom migrations:
|
|
# - Prefer SQL migrations when possible.
|
|
# - Never use application code: it can change and *will* break your migration.
|
|
# - Do not use Toucan models - refer table names directly.
|
|
# - If it's a big change, consider using Quartz, see #42279
|
|
# - More in `metabase.app_db.custom_migrations` namespace doc.
|
|
# - Never delete a migration: users won't be able to downgrade. If you really need to, see #44908
|
|
# - Migration id (`vXX.<date>`) must match its earliest released version:
|
|
# - Do not backport `v51....` to version 50, Metabase will try to downgrade it.
|
|
# - Instead, write a migration with an oldest target you plan to backport to in mind.
|
|
#
|
|
# 2) Migrations should go in the ###_update_migrations.yaml file for the target version.
|
|
#
|
|
# 3) Run mage lint-migrations-file to run core.spec checks against any changes you make here. Liquibase is pretty
|
|
# forgiving and won't complain if you accidentally mix up things like deleteCascade and onDelete: CASCADE. CI runs
|
|
# this check but it's nicer to know now instead of waiting for CI.
|
|
#
|
|
# 3) Migration IDs should follow the format
|
|
#
|
|
# vMM.TIMESTAMP
|
|
#
|
|
# Where
|
|
#
|
|
# M = major version
|
|
# TIMESTAMP = the current timestamp with format `yyyy-MM-dd'T'HH:mm:ss`
|
|
# To get this timestamp, evaluate this in your REPL: `(dev/migration-timestamp)`
|
|
#
|
|
# E.g: You're adding a new migration for version 49, And it's 10:30:00AM on April 1, 2023 (UTC),
|
|
# your migration id should be: `v49.2023-04-01T10:30:00`.
|
|
#
|
|
# PLEASE KEEP THIS MESSAGE AT THE BOTTOM OF THIS FILE!!!!! Add new migrations above the message.
|
|
#
|
|
########################################################################################################################
|