Room 3.0

  
रूम परसिस्टेंस लाइब्रेरी, SQLite को लेकर एक ऐब्स्ट्रैक्शन लेयर उपलब्ध कराती है, ताकि डेटाबेस को ज़्यादा अच्छे से ऐक्सेस किया जा सके. साथ ही, इसमें SQLite की सभी सुविधाओं का इस्तेमाल किया जा सकता है.
सबसे नया अपडेट अच्छी तरह काम करने वाला वर्शन रिलीज़ कैंडिडेट बीटा वर्शन ऐल्फ़ा वर्शन
19 मई, 2026 - - - 3.0.0-alpha05

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

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"
}

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

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

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

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

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

शानदार

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

Kotlin

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

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

शानदार

plugins {
    id 'androidx.room3'
}

room3 {
    schemaDirectory "$projectDir/schemas"
}

Kotlin

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-alpha05

19 मई, 2026

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

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

  • @Relation और @Junction को अपडेट किया गया है, ताकि parentColumns और entityColumns प्रॉपर्टी, कॉलम के नामों का एक ऐरे हो. इसका इस्तेमाल, रिलेशनशिप को हल करने के लिए कुंजियों के तौर पर किया जा सके. इससे, कंपोज़िट रिलेशनशिप कुंजियों को सपोर्ट किया जा सकेगा. (I92196, b/64247765)

वर्शन 3.0.0-alpha04

06 मई, 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

08 अप्रैल, 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 पेजिनेशन टारगेट: 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 केएमपी माइग्रेशन गाइड देखें.

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 के उलट, अब RoomDatabase को Executor के साथ कॉन्फ़िगर नहीं किया जा सकता. इसके बजाय, डेटाबेस के बिल्डर के ज़रिए, डिस्पैचर के साथ CoroutineContext उपलब्ध कराया जा सकता है.

InvalidationTracker एपीआई, Room 3.0 में 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 को भी टारगेट किया गया है. साथ ही, नए आर्टफ़ैक्ट androidx.sqlite:sqlite-web में मौजूद एक नया ड्राइवर WebWorkerSQLiteDriver भी जोड़ा गया है. इससे, सामान्य कोड में 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 भी शामिल है. हमारा सुझाव है कि इन एपीआई का इस्तेमाल तब किया जाए, जब प्रोजेक्ट वेब और नॉन-वेब प्लैटफ़ॉर्म, दोनों को टारगेट करता हो. ऐसा इसलिए, क्योंकि ये एपीआई, 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'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 और पेजिनेशन जैसे, डीएओ रिटर्न टाइप के अलग-अलग इंटिग्रेशन को, 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>
}

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

रिटर्न टाइप कन्वर्टर क्लास सह-प्रॉडक्ट
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

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