syncthing

mirror of https://github.com/syncthing/syncthing.git synced 2025-12-30 09:29:09 -05:00

Files

Simon Frei 4459438245 chore(db): update schema version in the same transaction as migration (#10321 )

Just to be entirely sure that if the migration succeeds the schema
version is always also updated. Currently if a migration succeeds but a
later migration doesn't, the changes of the migration apply but the
version stays - if the migration is breaking/non-idempotent, it will
fail when it tries to rerun it next time (otherwise it's just a
pointless re-execution).

Unfortunately with the current `db.runScripts` it wasn't that easy to
do, so I had to do quite a bit of refactoring. I am also ensuring the
right order of transactions now, though I assume that was already the
case lexicographically - can't hurt to be safe.

2025-08-30 13:18:31 +02:00

migrations/folder

fix(model): don't clobber local flags when receiving index (#10190 )

2025-06-20 07:08:06 +00:00

schema

refactor(db): slightly improve insert performance (#10318 )

2025-08-29 15:26:23 +02:00

README.md

chore(db): update schema version in the same transaction as migration (#10321 )

2025-08-30 13:18:31 +02:00

README.md

These SQL scripts are embedded in the binary.

Scripts in schema/ are run at every startup, in alphanumerical order.

Scripts in migrations/ are run when a migration is needed; they must begin with a number that equals the schema version that results from that migration. Only one script per schema version must exist. Migrations are not run on initial database creation, so the scripts in schema/ should create the latest version.