Skip to content

Update DB migrations style guide: prefer atomic migrations when possible

Mayra Cabrera requested to merge nik-db-migrations-prefer-atomic-docs into master

What does this MR do?

Recommend using atomic migrations when possible

Currently, the DB migrations guide says that "you must" use non-blocking operations (such as CREATE INDEX CONCURRENTLY), always. But this does not make sense in cases of empty tables and leads to splitting the work to multiple non-atomic (with disable_ddl_transaction!) DB migrations.

To follow KISS principle, to have fewer DB migrations steps, to have them atomic when it's possible and simplify deployment and troubleshooting, I'm adding exceptions to:

  • index creation
  • index dropping
  • defining an FK
  • adding a column with DEFAULT,

saying that if the target table is empty, it's completely normal and recommended to use regular, blocking methods (we will not block anyone if the target table is empty).

Additionally, grammar and style fixed/improved in multiple places.

⏳ Once reviewing of this MR is done, I'll make an EE port of it.

Related issues

No issues, this comes from MR reviewing experience.

Author's checklist

  • Follow the Documentation Guidelines and Style Guide.
  • Link docs to and from the higher-level index page, plus other related docs where helpful.
  • Apply the ~Documentation label.

Review checklist

All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Documentation Guidelines and Style Guide.

1. Primary Reviewer

  • Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.

2. Technical Writer

  • Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable DevOps stage.

3. Maintainer

  1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
  2. Ensure a release milestone is set and that you merge the equivalent EE MR before the CE MR if both exist.
  3. If there has not been a technical writer review, create an issue for one using the Doc Review template.
Edited by Mayra Cabrera

Merge request reports