Document migration rules for indexes and defaults

Clarify that indexes should not be added speculatively and
should only be introduced when justified by production query
latency. Also document that columns should avoid DEFAULT
clauses, with guidance on backfilling non-nullable columns.

Signed-off-by: Sacha Al Himdani <sacha@getprobo.com>
This commit is contained in:
Sacha Al Himdani
2026-03-20 10:47:18 +01:00
parent a69b6da377
commit 6e9cee9d34

View File

@@ -158,7 +158,11 @@ Each entity gets a unique `uint16` constant in `entity_type_reg.go`. **Never reu
## Migrations
Files in `pkg/coredata/migrations/` use timestamp naming: `YYYYMMDDTHHMMSSZ.sql` (UTC). One logical change per file. Always create indexes for frequently queried columns.
Files in `pkg/coredata/migrations/` use timestamp naming: `YYYYMMDDTHHMMSSZ.sql` (UTC). One logical change per file.
**No indexes by default.** Only add indexes when justified by observed query latency in production environments. Do not speculatively create indexes on new tables or columns. This rule does not apply to indexes that enforce constraints, such as unique indexes.
**Avoid default values.** Columns should not have `DEFAULT` clauses. When adding a non-nullable column to an existing table, use a `DEFAULT` to backfill existing rows, then drop it in the same migration.
## New entity checklist