Room 3.0

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

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

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

dependencies {
    val room_version = ""

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

dependencies {
    def room_version = ""

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

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

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

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

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

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

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

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

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

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

plugins {
    id 'androidx.room3'
}

room3 {
    schemaDirectory "$projectDir/schemas"
}

plugins {
    id("androidx.room3")
}

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

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

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

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

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

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

वर्शन 3.0

वर्शन 3.0.0-alpha04

6 मई, 2026

androidx.room3:room3-*:3.0.0-alpha04 रिलीज़ हो गया है. वर्शन 3.0.0-alpha04 में ये कमिट शामिल हैं.

एपीआई में किए गए बदलाव

• Room के कनेक्शन पूल को कॉन्फ़िगर करने के लिए, एपीआई जोड़े गए. बिल्डर फ़ंक्शन setSingleConnectionPool() और setMultipleConnectionPool() का इस्तेमाल करके, यह कंट्रोल किया जा सकता है कि Room, डेटाबेस से कनेक्ट होने के लिए ज़्यादा से ज़्यादा कितने कनेक्शन खोलेगा. (I9700d, b/438041176, b/432820350)
• Room के DatabaseConfiguration को सार्वजनिक एपीआई से हटा दिया गया है, क्योंकि किसी अन्य सार्वजनिक एपीआई में इस कॉन्फ़िगरेशन का रेफ़रंस नहीं दिया गया था. (I5f1e9, b/438041176)

गड़बड़ियां ठीक की गईं

• वेब टारगेट को सिर्फ़ एक कनेक्शन पूल का इस्तेमाल करने की अनुमति दी गई है, ताकि ओपीएफ़एस (b/496255935) के साथ होने वाली 'डेटाबेस लॉक' की समस्याओं से बचा जा सके.
• 'मेथड बहुत बड़ा है' गड़बड़ी को ठीक करने की कोशिश (फिर से) की गई है. यह गड़बड़ी, Room के ज़रिए बहुत बड़ा onValidateSchema जनरेट करने की वजह से होती है. इस फ़ंक्शन को स्टेटमेंट की संख्या के आधार पर बांटा जाता है, लेकिन मेज़रमेंट सटीक नहीं होता. अगर आपको अब भी यह गड़बड़ी दिखती है, तो Room के ज़रिए गिने जाने वाले स्टेटमेंट की संख्या को, एनोटेशन प्रोसेसर के विकल्प room.validationSplitSize की मदद से अडजस्ट किया जा सकता है. फ़िलहाल, डिफ़ॉल्ट वैल्यू 300 स्टेटमेंट पर सेट है. इसलिए, अगर समस्या अब भी बनी हुई है, तो कम संख्या का इस्तेमाल करें (b/493708172).

वर्शन 3.0.0-alpha03

8 अप्रैल, 2026

androidx.room3:room3-*:3.0.0-alpha03 रिलीज़ हो गया है. वर्शन 3.0.0-alpha03 में ये कमिट शामिल हैं.

एपीआई में किए गए बदलाव

• RoomDatabase के नो-आर्ग कंस्ट्रक्टर को सार्वजनिक किया गया है, ताकि @Database एलान में कंस्ट्रक्टर का रेफ़रंस दिए जाने पर, Lint की चेतावनी न मिले. (I9bac2, b/494722261)
• Room.inMemoryDatabaseBuilder और Room.databaseBuilder का एक ऐसा वर्शन जोड़ा गया है जो Android कॉन्टेक्स्ट में नहीं चलता. Room 3.0 में, कॉन्टेक्स्ट की ज़रूरत काफ़ी कम हो गई है. इसलिए, बिल्डर के लिए इसे वैकल्पिक वैल्यू बनाने से, सामान्य कोड में इन-मेमोरी डेटाबेस को ज़्यादा आसानी से बनाया जा सकता है. (I5d502, b/438041176)

गड़बड़ियां ठीक की गईं

• जेवीएम और Android के जनरेट किए गए कोड में, 'कोड बहुत बड़ा है' गड़बड़ी को ठीक किया गया है. यह गड़बड़ी, onValidateSchema फ़ंक्शन का मुख्य हिस्सा बहुत बड़ा होने की वजह से होती थी (b/493708172).

वर्शन 3.0.0-alpha02

25 मार्च, 2026

androidx.room3:room3-*:3.0.0-alpha02 रिलीज़ हो गया है. वर्शन 3.0.0-alpha02 में ये कमिट शामिल हैं.

नई सुविधाएं

• FTS5 की सुविधा: Room में @Fts5 एनोटेशन के ज़रिए, FTS5 की सुविधा जोड़ी गई है. इसमें, FTS5 टोकनाइज़र (TOKENIZER_ASCII और TOKENIZER_TRIGRAM) के लिए नए कॉन्स्टैंट और 'डिटेल' FTS विकल्प (FULL, COLUMN, और NONE) के लिए एक एनम शामिल है. (I90934, b/146824830)
• Room Paging टारगेट: room3-paging में js, wasmJs, tvOS, और watchOS टारगेट जोड़े गए हैं. (Icffd3, b/432783733)

एपीआई में किए गए बदलाव

• मल्टी-प्लैटफ़ॉर्म clearAllTables(): clearAllTables() को सामान्य बनाया गया है, ताकि यह सभी प्लैटफ़ॉर्म पर उपलब्ध हो. इसे suspend फ़ंक्शन में भी बदला गया है. (I434ae, b/322846465)
• डिस्ट्रक्टिव माइग्रेशन: fallbackToDestructiveMigration एपीआई में, dropAllTables में डिफ़ॉल्ट पैरामीटर वैल्यू जोड़ी गई है. (Ica88b, b/438041176)

• एक्सपेरिमेंटल एपीआई में किए गए बदलाव:

  1. @ExperimentalRoomApi को room-common में ले जाया गया है, ताकि एनोटेशन पर आधारित एपीआई को एक्सपेरिमेंटल के तौर पर मार्क किया जा सके.

  2. Room डेटाबेस के एलान में @ConstructedBy की ज़रूरत को खत्म करने के लिए, एक एक्सपेरिमेंटल RoomWarning जोड़ा गया है. इस मामले में, DatabaseConstructor जनरेट नहीं किया जाएगा. साथ ही, DatabaseBuilder के ज़रिए फ़ैक्ट्री का लागू होना ज़रूरी है. (If5443)

गड़बड़ियां ठीक की गईं

• पेजिंग सोर्स: PagingSourceDaoReturnTypeConverter को अपडेट किया गया है, ताकि यह सही तरीके से बताए कि इसका कन्वर्ट फ़ंक्शन, READ क्वेरी के लिए है. (I3b067, b/139872302)

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

Room 2.x और 3.0 के बीच मुख्य अंतर यहां दिए गए हैं:

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

Room 3.0 में, 2.x की तुलना में नई सुविधाएं भी जोड़ी गई हैं:

• जेएस और WasmJS की सुविधा
• कस्टम डीएओ रिटर्न टाइप

नया पैकेज

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

SupportSQLite एपीआई की सुविधा नहीं है

Room 3.0, SQLiteDriver एपीआई पर पूरी तरह से काम करता है. साथ ही, अब इसमें SupportSQLite टाइप, जैसे कि SupportSQLiteDatabase या Android टाइप, जैसे कि Cursor का रेफ़रंस नहीं दिया जाता. Room 3.0 और 2.x के बीच यह सबसे अहम बदलाव है, क्योंकि RoomDatabase एपीआई को हटा दिया गया है. ये एपीआई, SupportSQLiteDatabase के साथ-साथ, SupportSQLiteOpenHelper पाने के लिए इस्तेमाल किए जाते थे. अब 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 का इस्तेमाल किसी केएमपी प्रोजेक्ट में किया जा रहा था, तो 3.0 पर माइग्रेट करना आसान है, क्योंकि इसमें ज़्यादातर इंपोर्ट रेफ़रंस अपडेट करने होते हैं. हालांकि, Android-only से केएमपी में Room के लिए, माइग्रेशन की वही रणनीति लागू होती है. ज़्यादा जानकारी के लिए, Room KMP Migration Guide देखें.

SupportSQLite रैपर

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

Kotlin और कोरूटीन को प्राथमिकता

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

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

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

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

इस्तेमाल से जुड़ा उदाहरण:

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

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

सुविधा के लिए, androidx.sqlite पैकेज में, बताए गए एपीआई के सिंक्रोनस नामों के साथ सस्पेंड एक्सटेंशन फ़ंक्शन भी जोड़े गए हैं. इनमें SQLiteConnection.executeSQL को भी जोड़ा गया है. हमारा सुझाव है कि इन एपीआई का इस्तेमाल तब किया जाए, जब प्रोजेक्ट वेब और नॉन-वेब प्लैटफ़ॉर्म, दोनों को टारगेट करता हो. ऐसा इसलिए, क्योंकि ये एपीआई, प्लैटफ़ॉर्म के आधार पर सही वैरिएंट को कॉल करने वाले एलान / एक्चुअल एलान होते हैं. ये वे एपीआई हैं जिनका इस्तेमाल 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's WASM का इस्तेमाल करता है और डेटाबेस को ओपीएफ़एस में सेव करता है. उदाहरण के तौर पर दिया गया वर्कर, लोकल एनपीएम पैकेज के तौर पर पब्लिश किया जाता है. साथ ही, Kotlin में एनपीएम डिपेंडेंसी की सुविधा होने की वजह से, वर्कर को चलाने के लिए एक छोटा केएमपी मॉड्यूल बनाया जा सकता है.

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

प्रोजेक्ट में वर्कर सेट अप करने के बाद, वेब के लिए Room को कॉन्फ़िगर करना, अन्य प्लैटफ़ॉर्म के लिए 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)"""))

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

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

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

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

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

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

कॉलम टाइप कन्वर्टर की तरह, डीएओ रिटर्न टाइप कन्वर्टर को ऐप्लिकेशन से तय किया जा सकता है. उदाहरण के लिए, कोई ऐप्लिकेशन, वेब टाइप 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() }
    }
}

इसके बाद, ऊपर दिया गया कन्वर्टर, डीएओ क्वेरी फ़ंक्शन को 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() एपीआई के साथ मिलकर, ऑब्ज़र्वेबल / रिएक्टिव टाइप को सपोर्ट करने के लिए काम का है.
• rawQuery: RoomRawQuery: (ज़रूरी नहीं) इसमें रनटाइम पर क्वेरी का एक इंस्टेंस शामिल होता है. इससे, PagingSourceDaoReturnTypeConverter से लागू की गई LIMIT / OFFSET रणनीति जैसे बदलाव किए जा सकते हैं.
• executeAndConvert: suspend () -> T: (ज़रूरी) Room से जनरेट किया गया फ़ंक्शन, जो क्वेरी को लागू करेगा और उसके नतीजे को डेटा ऑब्जेक्ट में पार्स करेगा.

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