Skip to main content
Custom Content Schema Versioning
- Migrations run automatically in
openCustomContentDB(frontend/src/utils/indexeddb.js), which invokesrunMigrationsafter a successful open. - After migrations,
runMigrationscallsvalidateDataIntegrityand throwsDataIntegrityValidationError(defined infrontend/src/utils/migrations.js) if invalid records are found. openCustomContentDBtreatsDataIntegrityValidationError(instance, name, or code match) as a recoverable warning and continues to use the database; other errors still reject the open.- v2 - adds a
createdAttimestamp to items, processes, and quests. - v3 - adds an
updatedAttimestamp to all records.
Custom Content Schema Versioning
DSPACE tracks the structure of the custom content database with a numeric schema version stored in
the meta object store of the CustomContent IndexedDB database. When the app opens the database
via openCustomContentDB (frontend/src/utils/indexeddb.js), it calls runMigrations
(frontend/src/utils/migrations.js) to update older data and persist each schema step in meta.
Use getSchemaVersion to inspect the current value:
import { getSchemaVersion } from '../utils/indexeddb.js';
const version = await getSchemaVersion();
console.log(`Custom content schema version: ${version}`);
If IndexedDB is unavailable (for example, during server-side rendering or when no polyfill is
present), getSchemaVersion returns the current application constant
(CUSTOM_CONTENT_DB_VERSION in frontend/src/utils/indexeddb.js) so callers can still branch on
the expected schema version.
