Room 3.0

Room परसिस्टेंस लाइब्रेरी, SQLite को लेकर एक ऐब्स्ट्रैक्शन लेयर उपलब्ध कराती है, ताकि डेटाबेस को ज़्यादा अच्छे से ऐक्सेस किया जा सके.

नया अपडेट	स्टेबल रिलीज़	रिलीज़ कैंडिडेट	बीटा रिलीज़	ऐल्फ़ा रिलीज़
11 मार्च, 2026	-	-	-	3.0.0-alpha01

डिपेंडेंसी का एलान करना

Room3 पर डिपेंडेंसी जोड़ने के लिए, आपको अपने प्रोजेक्ट में Google Maven रिपॉज़िटरी जोड़नी होगी. ज़्यादा जानकारी के लिए, Google की Maven रिपॉज़िटरी पढ़ें.

अपने ऐप्लिकेशन या मॉड्यूल के लिए, build.gradle फ़ाइल में उन आर्टफ़ैक्ट की डिपेंडेंसी जोड़ें जिनकी आपको ज़रूरत है:

Kotlin

dependencies {
    val room_version = ""

    implementation("androidx.room3:room3-runtime:$room_version")
    ksp("androidx.room3:room3-compiler:$room_version")
}

Groovy

dependencies {
    def room_version = ""

    implementation "androidx.room3:room3-runtime:$room_version"

    ksp "androidx.room3:room3-compiler:$room_version"
}

KSP प्लगिन इस्तेमाल करने के बारे में जानकारी पाने के लिए, KSP का क्विक-स्टार्ट दस्तावेज़ देखें.

डिपेंडेंसी के बारे में ज़्यादा जानकारी के लिए, बिल्ड डिपेंडेंसी जोड़ना लेख पढ़ें.

Room Gradle प्लगिन का इस्तेमाल करना

Room कंपाइलर के लिए विकल्पों को कॉन्फ़िगर करने के लिए, Room Gradle प्लगिन का इस्तेमाल किया जा सकता है. यह प्लगिन, प्रोजेक्ट को इस तरह से कॉन्फ़िगर करता है कि जनरेट किए गए स्कीमा (जो कंपाइल टास्क का आउटपुट होते हैं और जिनका इस्तेमाल ऑटो-माइग्रेशन के लिए किया जाता है) सही तरीके से कॉन्फ़िगर किए जाएं. इससे, दोबारा बनाए जा सकने वाले और कैश किए जा सकने वाले बिल्ड तैयार किए जा सकते हैं.

प्लगिन जोड़ने के लिए, सबसे ऊपर के लेवल की Gradle बिल्ड फ़ाइल में, प्लगिन और उसका वर्शन तय करें.

Groovy

plugins {
    id 'androidx.room3' version "$room_version" apply false
}

Kotlin

plugins {
    id("androidx.room3") version "$room_version" apply false
}

मॉड्यूल-लेवल की Gradle बिल्ड फ़ाइल में, प्लगिन लागू करें और room3 एक्सटेंशन का इस्तेमाल करें.

Groovy

plugins {
    id 'androidx.room3'
}

room3 {
    schemaDirectory "$projectDir/schemas"
}

Kotlin

plugins {
    id("androidx.room3")
}

room3 {
    schemaDirectory("$projectDir/schemas")
}

Room Gradle Plugin का इस्तेमाल करते समय, schemaDirectory सेट करना ज़रूरी है. इससे Room कंपाइलर और कंपाइल करने से जुड़े अलग-अलग टास्क और इसके बैकएंड (kotlinc, KSP) कॉन्फ़िगर हो जाएंगे. ये फ़्लेवर्ड फ़ोल्डर में स्कीमा फ़ाइलें आउटपुट करेंगे. उदाहरण के लिए, schemas/flavorOneDebug/com.package.MyDatabase/1.json. इन फ़ाइलों को रिपॉज़िटरी में सेव किया जाना चाहिए, ताकि इनका इस्तेमाल पुष्टि करने और अपने-आप माइग्रेट होने की सुविधा के लिए किया जा सके.

सुझाव/राय दें या शिकायत करें

आपके सुझाव, शिकायत या राय से Jetpack को बेहतर बनाने में मदद मिलती है. अगर आपको कोई नई समस्या मिलती है या आपके पास इस लाइब्रेरी को बेहतर बनाने के लिए सुझाव हैं, तो हमें बताएं. कृपया नई समस्या सबमिट करने से पहले, इस लाइब्रेरी में शामिल मौजूदा समस्याओं को देखें. स्टार बटन पर क्लिक करके, किसी मौजूदा समस्या के लिए वोट किया जा सकता है.

नई समस्या दर्ज करने का तरीका

ज़्यादा जानकारी के लिए, Issue Tracker का दस्तावेज़ देखें.

वर्शन 3.0

वर्शन 3.0.0-alpha01

11 मार्च, 2026

androidx.room3:room3-*:3.0.0-alpha01 रिलीज़ हो गया है.

Room 3.0 (पैकेज androidx.room3), Room 2.x पैकेज (androidx.room) का मुख्य वर्शन अपडेट है. यह Kotlin Multiplatform (केएमपी) पर फ़ोकस करता है.

मुख्य कॉम्पोनेंट के साथ-साथ, मुख्य एनोटेशन एपीआई को भी पहले जैसा ही रखा गया है:

androidx.room3.RoomDatabase से एक्सटेंड होने वाली और @Database से एनोटेट की गई ऐब्सट्रैक्ट क्लास, Room के एनोटेशन प्रोसेसर का एंट्री पॉइंट होती है.
डेटाबेस के एलान में एक या उससे ज़्यादा डेटा क्लास होती हैं. इनमें डेटाबेस स्कीमा के बारे में बताया जाता है और इन्हें @Entity के साथ एनोटेट किया जाता है.
डेटाबेस के ऑपरेशन, @Dao डिक्लेरेशन में तय किए जाते हैं. इनमें क्वेरी फ़ंक्शन होते हैं. इनके एसक्यूएल स्टेटमेंट, @Query एनोटेशन के ज़रिए तय किए जाते हैं.
रनटाइम के दौरान, डेटाबेस को लागू करने की सुविधा RoomDatabase.Builder के ज़रिए मिलती है. इसका इस्तेमाल डेटाबेस को कॉन्फ़िगर करने के लिए भी किया जाता है.

रूम का इस्तेमाल करके, डेटा को किसी स्थानीय डेटाबेस में सेव करना गाइड में मौजूद ज़्यादातर दस्तावेज़, अब भी Room 3.0 के लिए काम के हैं.

Room 2.x में ये बड़े बदलाव किए गए हैं:

नया पैकेज, androidx.room3.
SupportSQLite API अब काम नहीं करते. हालांकि, अगर androidx.room3:room3-sqlite-wrapper का इस्तेमाल किया जा रहा है, तो ये काम करेंगे.
डेटाबेस से जुड़ी सभी कार्रवाइयां अब Coroutine API पर आधारित हैं.
सिर्फ़ Kotlin कोड जनरेट करने की सुविधा.
Kotlin Symbol Processing (KSP) की ज़रूरत होती है.

Room 3.0 में, 2.x की तुलना में नई सुविधाएं जोड़ी गई हैं. हालांकि, इसमें कुछ ऐसे बदलाव भी किए गए हैं जिनकी वजह से, पहले से मौजूद कोड काम नहीं करेगा:

JS और WasmJS के साथ काम करता है
कस्टम DAO के रिटर्न टाइप

नया पैकेज

Room 2.x के मौजूदा वर्शन के साथ काम करने से जुड़ी समस्याओं को रोकने के लिए, Room 3.0 को नए पैकेज में रखा गया है. साथ ही, Room पर ट्रांज़िटिव डिपेंडेंसी वाली लाइब्रेरी (उदाहरण के लिए, WorkManager) के लिए भी ऐसा किया गया है. इसका मतलब है कि इसमें नया मेवन ग्रुप और आर्टफ़ैक्ट आईडी भी है. उदाहरण के लिए, androidx.room:room-runtime अब androidx.room3:room3-runtime हो गया है. साथ ही, androidx.room.RoomDatabase जैसी क्लास अब androidx.room3.RoomDatabase पर मौजूद होंगी.

SupportSQLite API उपलब्ध नहीं हैं

Room 3.0, पूरी तरह से SQLiteDriver API पर आधारित है. साथ ही, यह अब SupportSQLite टाइप का रेफ़रंस नहीं देता है. जैसे, SupportSQLiteDatabase या Android टाइप, जैसे कि Cursor. Room 3.0 और 2.x के बीच यह सबसे अहम बदलाव है. ऐसा इसलिए, क्योंकि RoomDatabase से मिलते-जुलते RoomDatabase एपीआई के साथ-साथ SupportSQLiteOpenHelper पाने के लिए एपीआई को हटा दिया गया है.SupportSQLiteDatabase RoomDatabase बनाने के लिए, अब SQLiteDriver ज़रूरी है.

उदाहरण के लिए, डेटाबेस से जुड़ी कार्रवाइयों के लिए इस्तेमाल होने वाले एपीआई को ड्राइवर के बराबर की सुविधाओं से बदल दिया जाता है:

// Room 2.x
roomDatabase.runInTransaction { ... }

// Room 3.x
roomDatabase.withWriteTransaction { ... }

// Room 2.x
roomDatabase.query("SELECT * FROM Song").use { cursor -> ... }

// Room 3.x
roomDatabase.useReaderConnection { connection ->
  connection.usePrepared("SELECT * FROM Song") { stmt -> ... }
}

जिन कॉलबैक एपीआई में SupportSQLiteDatabase को आर्ग्युमेंट के तौर पर इस्तेमाल किया गया था उन्हें भी उनके जैसे एपीआई से बदल दिया गया है. इन एपीआई में SQLiteConnection को आर्ग्युमेंट के तौर पर इस्तेमाल किया जाता है. ये माइग्रेशन कॉलबैक फ़ंक्शन हैं, जैसे कि Migration.onMigrate() और AutoMigrationSpec.onPostMigrate(). इनके साथ-साथ, डेटाबेस कॉलबैक भी हैं, जैसे कि RoomDatabase.Callback.onCreate(), RoomDatabase.Callback.onOpen() वगैरह.

अगर Room का इस्तेमाल KMP प्रोजेक्ट में किया जा रहा था, तो 3.0 पर माइग्रेट करना आसान है. ऐसा इसलिए, क्योंकि इसमें इंपोर्ट रेफ़रंस अपडेट करने होते हैं. हालांकि, अगर Room का इस्तेमाल सिर्फ़ Android में किया जा रहा था, तो KMP पर माइग्रेट करने के लिए वही रणनीति लागू होती है. इसके बारे में जानने के लिए, Room KMP माइग्रेशन गाइड देखें.

SupportSQLite रैपर

Room 3.x, माइग्रेशन को आसान बनाने के लिए 2.x में बनाए गए SupportSQLite रैपर को बनाए रखता है. साथ ही, अब यह नए आर्टफ़ैक्ट androidx.room3:room3-sqlite-wrapper में मौजूद है. Compatibility API की मदद से, RoomDatabase को SupportSQLiteDatabase में बदला जा सकता है. roomDatabase.openHelper.writableDatabase के बजाय roomDatabase.getSupportWrapper() का इस्तेमाल किया जा सकता है.

Kotlin and Coroutines First

लाइब्रेरी को बेहतर बनाने के लिए, Room 3.0 सिर्फ़ Kotlin कोड जनरेट करता है. साथ ही, यह सिर्फ़ Kotlin सिंबल प्रोसेसर (केएसपी) है. Room 2.x की तुलना में, Room 3.0 में Java कोड जनरेट नहीं होता है. साथ ही, KAPT या JavaAP के ज़रिए एनोटेशन प्रोसेसर को कॉन्फ़िगर नहीं किया जा सकता. ध्यान दें कि KSP, Java सोर्स को प्रोसेस कर सकता है. साथ ही, Room कंपाइलर, डेटाबेस, इकाइयों या DAO के लिए कोड जनरेट करेगा. इनके सोर्स डिक्लेरेशन, Java में होते हैं. हमारा सुझाव है कि आपके पास एक मल्टी-मॉड्यूल प्रोजेक्ट हो. इसमें Room का इस्तेमाल किया जाता हो. साथ ही, Kotlin Gradle Plugin और KSP को लागू किया जा सकता हो. इससे बाकी कोडबेस पर कोई असर नहीं पड़ता.

Room 3.0 के लिए भी Coroutines का इस्तेमाल करना ज़रूरी है. खास तौर पर, DAO फ़ंक्शन को सस्पेंड करना होगा. ऐसा तब तक करना होगा, जब तक वे रिएक्टिव टाइप नहीं दिखा रहे हैं. जैसे, Flow या कस्टम DAO रिटर्न टाइप. डेटाबेस से जुड़े ऑपरेशन करने के लिए Room API भी सस्पेंड फ़ंक्शन होते हैं. जैसे, RoomDatabase.useReaderConnection और RoomDatabase.useWriterConnection.

Room 2.x के उलट, अब Executor को Executor के साथ कॉन्फ़िगर नहीं किया जा सकता. इसके बजाय, डेटाबेस के बिल्डर के ज़रिए CoroutineContext के साथ-साथ डिस्पैचर भी दिया जा सकता है.RoomDatabase

InvalidationTracker Room 3.0 में मौजूद एपीआई, Flow पर आधारित हैं. InvalidationTracker.Observer को इससे जुड़े एपीआई addObserver और removeObserver के साथ हटा दिया गया है. डेटाबेस के ऑपरेशन पर प्रतिक्रिया देने का तरीका, कोरूटीन फ़्लो के ज़रिए होता है. इन्हें createFlow() में InvalidationTracker के ज़रिए बनाया जा सकता है.

इस्तेमाल का उदाहरण:

fun getArtistTours(from: Date, to: Date): Flow<Map<Artist, TourState>> {
    return db.invalidationTracker.createFlow("Artist").map { _ ->
        val artists = artistsDao.getAllArtists()
        val tours = tourService.fetchStates(artists.map { it.id })
        associateTours(artists, tours, from, to)
    }
}

वेब पर सहायता

Room 3.0 की रिलीज़ में, JavaScript और WasmJs को KMP टारगेट के तौर पर जोड़ा गया है. SQLiteDriver इंटरफ़ेस (androidx.sqlite:sqlite) के रिलीज़ होने के साथ-साथ, JavaScript और WasmJs को टारगेट करने वाले नए ड्राइवर WebWorkerSQLiteDriver को नए आर्टफ़ैक्ट androidx.sqlite:sqlite-web में शामिल किया गया है. इससे, सामान्य कोड में Room का इस्तेमाल किया जा सकता है. यह कोड, सभी मुख्य KMP प्लैटफ़ॉर्म को टारगेट करता है.

वेब प्लैटफ़ॉर्म के एसिंक्रोनस होने की वजह से, Room API जो SQLiteStatement को आर्ग्युमेंट के तौर पर लेते थे वे अब निलंबित फ़ंक्शन हैं. इन फ़ंक्शन के उदाहरण Migration.onMigrate(), RoomDatabase.Callback.onCreate(), PooledConnection.usePrepared() वगैरह हैं. ड्राइवर एपीआई में, एसिंक्रोनस एपीआई सभी प्लैटफ़ॉर्म पर आम तौर पर इस्तेमाल होते हैं. वहीं, सिंक्रोनस एपीआई, नॉन-वेब टारगेट के लिए आम तौर पर इस्तेमाल होते हैं. इसलिए, वेब को टारगेट न करने वाला प्रोजेक्ट, सामान्य कोड में सिंक्रोनस एपीआई (SQLiteDriver.open(), SQLiteConnection.prepare(), और SQLiteStatement.step()) का इस्तेमाल जारी रख सकता है. वहीं, सिर्फ़ वेब को टारगेट करने वाले प्रोजेक्ट को असिंक्रोनस एपीआई (SQLiteDriver.openAsync(), SQLiteConnection.prepareAsync(), और SQLiteStatement.stepAsync()) का इस्तेमाल करना चाहिए.

आसानी के लिए, androidx.sqlite पैकेज ने बताए गए एपीआई के सिंक्रोनस नामों के साथ, निलंबन एक्सटेंशन फ़ंक्शन भी जोड़े हैं. इनमें SQLiteConnection.executeSQL भी शामिल है. जब प्रोजेक्ट, वेब और नॉन-वेब, दोनों प्लैटफ़ॉर्म को टारगेट करता है, तब इन एपीआई का इस्तेमाल करने का सुझाव दिया जाता है. ऐसा इसलिए, क्योंकि एपीआई, expect / actual डिक्लेरेशन होते हैं. ये प्लैटफ़ॉर्म के आधार पर सही वैरिएंट को कॉल करेंगे. ये ऐसे एपीआई हैं जिनका इस्तेमाल Room के रनटाइम में किया जाता है. साथ ही, ये सभी प्लैटफ़ॉर्म पर ड्राइवर के इस्तेमाल को चालू करते हैं.

इस्तेमाल का उदाहरण:

import androidx.sqlite.executeSQL
import androidx.sqlite.step

roomDatabase.useWriterConnection { connection ->
    val deletedSongs = connection.usePrepared(
        "SELECT count(*) FROM Song"
    ) { stmt ->
        stmt.step()
        stmt.getLong(0)
    }
    connection.executeSQL("DELETE FROM Song")
    deletedSongs
}

WebWorkerSQLiteDriver, SQLiteDriver का एक ऐसा वर्शन है जो मुख्य थ्रेड से अलग डेटाबेस ऑपरेशन करने के लिए, वेब वर्कर से कम्यूनिकेट करता है. साथ ही, यह डेटाबेस को ऑरिजिन प्राइवेट फ़ाइल सिस्टम (ओपीएफ़एस) में सेव करने की सुविधा देता है. ड्राइवर को इंस्टैंशिएट करने के लिए, एक ऐसे वर्कर की ज़रूरत होती है जो सामान्य कम्यूनिकेशन प्रोटोकॉल लागू करता हो. इस प्रोटोकॉल के बारे में WebWorkerSQLiteDriver KDoc में बताया गया है.

फ़िलहाल, WebWorkerSQLiteDriver के साथ डिफ़ॉल्ट वर्कर नहीं मिलता है. यह वर्कर, कम्यूनिकेशन प्रोटोकॉल लागू करता है. हालांकि, उदाहरण के तौर पर, androidx कोडबेस में वर्कर लागू करने का तरीका शामिल है. इसका इस्तेमाल आपके प्रोजेक्ट में किया जा सकता है. यह SQLite के WASM का इस्तेमाल करता है और डेटाबेस को OPFS में सेव करता है. उदाहरण के तौर पर दिए गए वर्कर को लोकल NPM पैकेज के तौर पर पब्लिश किया जाता है. साथ ही, Kotlin में NPM डिपेंडेंसी इस्तेमाल करने की सुविधा की मदद से, वर्कर को चलाने के लिए एक छोटा KMP मॉड्यूल बनाया जा सकता है.

Room के लिए लोकल वेब वर्कर के इस्तेमाल का तरीका दिखाने वाला यह GitHub प्रोजेक्ट देखें.

प्रोजेक्ट में वर्कर सेट अप करने के बाद, वेब के लिए Room को कॉन्फ़िगर करने का तरीका अन्य प्लैटफ़ॉर्म के जैसा ही होता है:

fun createDatabase(): MusicDatabase {
    return Room.databaseBuilder<MusicDatabase>("music.db")
        .setDriver(WebWorkerSQLiteDriver(createWorker()))
        .build()
}

fun createWorker() =
    Worker(js("""new URL("sqlite-web-worker/worker.js", import.meta.url)"""))

वेब ड्राइवर के आने वाले वर्शन में, NPM में पब्लिश किया गया डिफ़ॉल्ट वर्कर शामिल हो सकता है. इससे वेब सेटअप करना आसान हो जाएगा.

कस्टम डीएओ के रिटर्न टाइप

DAO के अलग-अलग रिटर्न टाइप इंटिग्रेशन, जैसे कि RxJava और Paging के लिए, Room 3.0 में DAO रिटर्न टाइप कन्वर्टर नाम के नए एपीआई का इस्तेमाल किया गया है. DAO रिटर्न टाइप कन्वर्टर फ़ंक्शन (@DaoReturnTypeConverter) की मदद से, DAO फ़ंक्शन के नतीजे को एनोटेट किए गए फ़ंक्शन के ज़रिए तय किए गए कस्टम टाइप में बदला जा सकता है. इन फ़ंक्शन की मदद से, Room के जनरेट किए गए कोड में हिस्सा लिया जा सकता है. यह कोड, क्वेरी के नतीजों को डेटा ऑब्जेक्ट में बदलता है. जिन क्लास में DAO के रिटर्न टाइप कन्वर्टर होते हैं उन्हें @Database या @Dao डिक्लेरेशन में @DaoReturnTypeConverters एनोटेशन के ज़रिए रजिस्टर करना होता है.

उदाहरण के लिए, अगर आपको डीएओ क्वेरी से PagingSource वापस पाना है, तो अब androidx.room3:room3-paging में मौजूद कनवर्टर क्लास को रजिस्टर करना होगा:

@Dao
@DaoReturnTypeConverters(PagingSourceDaoReturnTypeConverter::class)
interface MusicDao {
    @Query("SELECT * FROM Song)
    fun getSongsPaginated(): PagingSource<Int, Song>
}

मौजूदा इंटिग्रेशन को DAO के रिटर्न टाइप कन्वर्टर में ले जाया गया है:

रिटर्न टाइप	कन्वर्टर क्लास	सह-प्रॉडक्ट
PagingSource	PagingSourceDaoReturnTypeConverter	androidx.room3:room3-paging
Observable, Flowable, Completable, Single, Maybe	RxDaoReturnTypeConverters	androidx.room3:room3-rxjava3
ListenableFuture	GuavaDaoReturnTypeConverter	androidx.room3:room3-guava
LiveData	LiveDataDaoReturnTypeConverter	androidx.room3:room3-livedata

कॉलम टाइप कन्वर्टर की तरह, DAO के रिटर्न टाइप कन्वर्टर को ऐप्लिकेशन से तय किया जा सकता है. उदाहरण के लिए, कोई ऐप्लिकेशन वेब टाइप kotlin.js.Promise के लिए @DaoReturnTypeConverter का एलान कर सकता है.

object PromiseDaoReturnTypeConverter {
    @DaoReturnTypeConverter([OperationType.READ, OperationType.WRITE])
    fun <T> convert(
        db: RoomDatabase,
        executeAndConvert: suspend () -> T
    ): Promise<T> {
        return db.getCoroutineScope().promise { executeAndConvert() }
    }
}

इसके बाद, ऊपर दिया गया कनवर्टर, DAO क्वेरी फ़ंक्शन को Promise वापस लाने की अनुमति देता है:

@Dao
@DaoReturnTypeConverters(PromiseDaoReturnTypeConverter::class)
interface MusicDao {
    @Query("SELECT * FROM Song")
    fun getAllSongs(): Promise<List<Song>>
}

@DaoReturnTypeConverter फ़ंक्शन के लिए, पैरामीटर की संख्या और उनके टाइप से जुड़ी कुछ ज़रूरी शर्तें हैं. ये पैरामीटर इस्तेमाल किए जा सकते हैं:

db: RoomDatabase: (ज़रूरी नहीं) RoomDatabase इंस्टेंस का ऐक्सेस देता है. यह अतिरिक्त डेटाबेस ऑपरेशन करने या कोराउटीन स्कोप को ऐक्सेस करने के लिए काम आ सकता है.
tableNames: Array<String>: (ज़रूरी नहीं) इसमें क्वेरी की ऐक्सेस की गई टेबल शामिल होती हैं. यह Room के InvalidationTracker.createFlow() API के साथ मिलकर काम करने पर, ऑब्ज़र्वेबल / रिएक्टिव टाइप को सपोर्ट करने के लिए फ़ायदेमंद होती है.
rawQuery: RoomRawQuery: (ज़रूरी नहीं) इसमें रनटाइम के दौरान क्वेरी का एक इंस्टेंस होता है. इससे PagingSourceDaoReturnTypeConverter की ओर से लागू की गई LIMIT / OFFSET रणनीति जैसे बदलाव किए जा सकते हैं.
executeAndConvert: suspend () -> T: (ज़रूरी है) Room से जनरेट किया गया ऐसा फ़ंक्शन जो क्वेरी को एक्ज़ीक्यूट करेगा और उसके नतीजे को डेटा ऑब्जेक्ट में पार्स करेगा.

DAO रिटर्न टाइप कन्वर्टर बनाने की ज़रूरी शर्तों के बारे में ज़्यादा जानने के लिए, @DaoReturnTypeConverter एपीआई पर KDoc देखें.