← ClaudeAtlas

android-room-databaselisted

Room database patterns for Android - database module boundaries, entities, DAOs, transactions, relations, migrations, converters, and offline-first persistence. Use this skill whenever adding Room entities or DAOs, changing schemas, writing queries, creating migrations, or deciding where shared database code should live. Trigger on phrases like "Room", "DAO", "entity", "migration", "type converter", "transaction", "query", "database module", or "offline-first persistence".
lenorebreakneck630/claude-zero-to-hero-android-KMP · ★ 1 · Data & Documents · score 64
Install: claude install-skill lenorebreakneck630/claude-zero-to-hero-android-KMP
# Android Room Database ## Core Principles - Room is the local persistence layer, not the domain model layer. - Entities are data-layer types only; never expose them to presentation. - DAOs should be focused and query-driven. - Prefer Room as the single source of truth when offline-first behavior is required. - Keep schema ownership explicit — shared DB code belongs in a core database module when multiple features use it. --- ## Recommended Module Ownership Use a dedicated `:core:database` module when the app has a shared Room database used by multiple features: ```text :core:database -> RoomDatabase, entities, DAOs, migrations, converters :core:data -> shared repository/data-source utilities :feature:<name>:data -> mappers and feature-specific data sources using DAOs ``` If only one feature uses Room and the schema is small, it can stay in that feature's `data` module until reuse justifies extraction. See the **android-module-structure** skill for extraction rules. --- ## Entities Entities model how data is stored locally, not how it is shown or used in domain logic: ```kotlin @Entity(tableName = "notes") data class NoteEntity( @PrimaryKey val id: String, val title: String, val body: String, val updatedAtEpochMillis: Long ) ``` Guidelines: - keep entities flat and storage-oriented - prefer primitive columns over nested object graphs - store foreign keys explicitly - use clear table names - avoid putting comput