Mobile App Database Migrations: SQLite, Room, and Core Data Quiz Quiz

Enhance your knowledge of database migrations in mobile app development with questions covering SQLite, Room, and Core Data. Understand key concepts such as schema versioning, migration strategies, and handling data changes across updates in mobile applications.

  1. Migrating Table Columns

    When adding a new column to an existing table during a SQLite migration, which statement is commonly used to update the table schema without losing data?

    1. VACUUM
    2. CREATE INDEX ...
    3. ALTER TABLE ... ADD COLUMN ...
    4. DROP TABLE ...

    Explanation: The 'ALTER TABLE ... ADD COLUMN ...' statement lets you add a new column to an existing SQLite table without deleting existing rows, ensuring data is preserved. 'DROP TABLE ...' would delete the entire table and all its data, which is not desirable when migrating. 'CREATE INDEX ...' is used for indexing, not altering columns. 'VACUUM' cleans up the database but does not change table structure.

  2. Handling Primary Keys

    In schema migrations, what must you ensure when changing a primary key's type from INTEGER to TEXT in an existing table used by a mobile app?

    1. Reset the auto-increment sequence
    2. Delete all rows before changing the type
    3. You need to create a new table and copy data over
    4. Simply rename the column

    Explanation: SQLite does not support altering the type of an existing column directly; you must create a new table with the desired schema, copy the data, and then replace the old table. Renaming only changes the column's label, not its data type. Deleting all rows does not alter the structure, and resetting the auto-increment sequence is unrelated to type changes.

  3. Automatic Migration Tools

    Which feature in some mobile frameworks helps automate migration paths by comparing old and new data models, reducing manual code for developers?

    1. Transaction Logging
    2. Database Vacuuming
    3. Foreign Keys
    4. Schema Diffing

    Explanation: Schema diffing compares previous and current database schemas to generate migration steps automatically, making migrations easier for developers. Foreign keys define relationships, not migrations. Database vacuuming clears storage, and transaction logging records changes but does not generate migration paths.

  4. Migration Failure Handling

    What is the recommended action if a migration fails during an app update, leaving the database in an inconsistent state?

    1. Rollback or restore from backup
    2. Continue loading the main screen
    3. Drop all user tables
    4. Ignore and suppress errors

    Explanation: Rolling back or restoring from a backup preserves user data integrity after a failed migration. Continuing to load the main screen may result in crashes or data corruption. Suppressing errors hides issues without resolution. Dropping all user tables leads to data loss.

  5. Room Version Control

    When using versioned migrations in Room, what triggers the onUpgrade callback to execute migration logic?

    1. The app is reinstalled
    2. An insert statement is executed
    3. The stored database version number increases
    4. The database file is deleted

    Explanation: onUpgrade is called when the database version number set in the app is higher than the version stored in the device, signaling the need to migrate. Deleting the database file resets the versioning process. Inserting data or reinstalling the app does not invoke migration callbacks by themselves.

  6. Core Data Lightweight Migration

    Which type of migration in Core Data can be performed automatically when changes are simple, such as adding a new property to an entity?

    1. Partial-migration
    2. Lightweight migration
    3. Heavyweight migration
    4. Manual-migration

    Explanation: Lightweight migration is designed for simple changes like adding properties, allowing automatic migration without extra code. Heavyweight migration is for complex changes requiring custom migration logic. 'Partial-migration' and 'Manual-migration' are not standard Core Data terms.

  7. Adding Indexes During Migration

    If you want to improve search speed for a commonly queried column during a migration, which action should you take?

    1. Remove and reinsert all rows
    2. Rename the column
    3. Reduce database file size
    4. Create an index on that column

    Explanation: Creating an index speeds up search operations on that column, especially after migrations that add more data. Renaming the column does not impact search speed. Removing and reinserting rows is unnecessary. Reducing file size can help performance with storage but not specific query speed.

  8. Migrating Relationships

    What is the recommended approach when converting a one-to-one relationship to a one-to-many relationship in a mobile app database migration?

    1. Increase database cache size
    2. Delete all child rows
    3. Merge both tables into one
    4. Introduce a foreign key referencing the parent

    Explanation: Introducing a foreign key allows multiple child rows to reference the same parent, properly representing a one-to-many relationship. Increasing the cache size is unrelated. Merging tables may reduce clarity and data integrity. Deleting all child rows results in data loss.

  9. Migration Testing Importance

    Why is it important to test migrations before releasing an updated mobile app to users?

    1. To avoid creating backup copies
    2. To double app loading time
    3. To increase the number of columns automatically
    4. To prevent data loss or corruption during upgrades

    Explanation: Testing migrations ensures user data remains intact and accessible after app updates, reducing the risk of app crashes or inconsistencies. Doubling loading time is not desirable, and migrations do not add columns automatically. Skipping backups before migrations is risky and not a reason for testing.

  10. Forgetting to Update Version Number

    What can happen if a developer forgets to increase the database version number after making schema changes in a mobile app?

    1. The migration will not run and data may not match code expectations
    2. Old data will be automatically deleted
    3. The app will auto-detect the changes and update the schema
    4. The app will revert to a backup

    Explanation: If the version number is not updated, migration callbacks are not triggered, so the database may be out of sync with the app code, causing errors. Apps generally do not auto-detect schema changes or update automatically. Automatic data deletion or backup restoration does not usually occur in these scenarios.