Skip to documentation content

Developer Reference

Protect schema migrations and data integrity

Plan additive migrations, locks, snapshots and rollback behavior without treating documentation or themes as a database authority.

The package that owns a table owns its schema, migration, compatibility and rollback contract. Prefer additive, non-destructive changes with explicit version options, transactional writes and a safe read fallback. A theme never queries tables or performs a migration; it consumes a public view model.

Integrity checklist

  • Pin the starting schema and exact Free/Pro pair before writing a migration.
  • Acquire the documented row or source lock, recheck configuration and final availability inside the transaction, and use savepoints for nested services.
  • Write booking items, services, coupons, tax lines, payment references and locale values as immutable snapshots. Historical reads must not recalculate live rules.
  • For iCal, reconcile a complete source snapshot atomically. Preserve the last known good external blocks after a fetch or parse error, and never commit a partial snapshot.
  • Make provider callbacks, imports and retries idempotent. A duplicate event must not create another booking, payment or external block.
  • Test fresh install, direct update, interrupted migration and rollback. A rollback of theme files must not silently roll back booking or payment data.

Document destructive cleanup, retention and recovery ownership explicitly. A release-blocking P0 includes data loss, incorrect money, incorrect booking or overbooking; do not waive it as a visual regression.

Next: validate package updates and compatibility metadata.

Was this article helpful?

Your feedback helps us improve the documentation.