42 lines
2.3 KiB
Markdown
42 lines
2.3 KiB
Markdown
# Migration numbering
|
|
|
|
Upstream (`iamxvbaba/gramsrv`) numbers its migrations sequentially
|
|
(`0001`, `0002`, ..., currently up to `0092`). This fork periodically merges
|
|
upstream, and upstream keeps adding its own sequentially-numbered migrations
|
|
between syncs.
|
|
|
|
**Any new OwpenGram-specific migration must use a `YYYYMMDDHHMMSS` timestamp
|
|
as its version instead of continuing the sequential numbering** — e.g.
|
|
`20260713103024_owpengram_system_account_brand.up.sql`.
|
|
|
|
Why: golang-migrate treats the version as a plain number and only cares
|
|
about ordering, not format. If we keep picking "the next free sequential
|
|
number" for our own migrations, the next upstream sync is very likely to
|
|
have independently picked the *same* number for one of its own new
|
|
migrations — two different new files, so git sees no conflict, and the
|
|
collision only surfaces at server startup (`iofs source: failed to init
|
|
driver ... duplicate migration file`, see `deploy/deploy_test.go`'s
|
|
`TestMigrationsLoad` for the regression test that now catches this at
|
|
`go test` time instead). This happened once already (our `0086`-`0088`
|
|
collided with upstream's own new `0086`-`0088`), and renumbering our
|
|
migrations to fit after upstream's (`0093`-`0095`) would only have deferred
|
|
the exact same problem to the *next* sync.
|
|
|
|
A 14-digit timestamp is always numerically larger than upstream's 4-5 digit
|
|
sequential numbers, so it always sorts after everything upstream has today
|
|
or will plausibly reach, and it never collides with another OwpenGram
|
|
migration as long as two aren't created in the same second. No renumbering
|
|
is ever needed again on future syncs — just keep using the timestamp at the
|
|
time the migration is written.
|
|
|
|
Upstream's own migrations keep their original sequential numbers untouched;
|
|
only migrations authored in this fork use the timestamp scheme.
|
|
|
|
## Removed feature: Stars, Star Gifts, Account Rating
|
|
|
|
The Stars economy, Star Gifts (collectibles/NFT gifts, local TON ledger),
|
|
and the Account Rating system were fully removed from the server (all
|
|
application/domain/store code and admin panel UI deleted). Their migrations
|
|
stay in place unmodified and are not reverted — this repo's convention is to
|
|
never renumber or delete migration history. The corresponding tables are
|
|
inert/orphaned as of the removal; this is intentional, not an oversight.
|