Add enterprise appliance experience Phase 1 foundation
This commit is contained in:
1 parent
b3eec34158
commit
ebaa2e7219
69 files changed
+6832
-18
No files matched your search
@@ -0,0 +1,26 @@
|
||||
# SQLite Migration and Rollback Procedure
|
||||
|
||||
## Rules
|
||||
|
||||
1. Read the current schema version before application startup writes new data.
|
||||
2. Create a verified pre-migration backup of the database and required companion state.
|
||||
3. Apply sequential idempotent migrations in one exclusive transaction where SQLite permits.
|
||||
4. Record the new version only after all statements and validation checks succeed.
|
||||
5. On failure, roll back the transaction, preserve the original database and record a redacted error.
|
||||
6. Never downgrade destructively. Restore the pre-migration backup when rollback requires an older
|
||||
application version.
|
||||
|
||||
## Validation
|
||||
|
||||
- Fresh database reaches the latest version.
|
||||
- Each supported previous version upgrades exactly once.
|
||||
- Re-running the migration is a no-op.
|
||||
- Interrupted/failed migration leaves a usable prior database or verified recovery copy.
|
||||
- Existing users, sessions, audit history, licensing state, settings and supported customer data
|
||||
remain readable.
|
||||
- Backup compatibility is checked before any restore mutation.
|
||||
|
||||
## Rollback Evidence
|
||||
|
||||
Record source and target schema versions, backup path/checksum, start/end time, result, correlation ID,
|
||||
validation outcome, and recovery action without storing secrets or customer content.
|
||||
Reference in new issue
Block a user