Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Room 3.0

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

नया अपडेट	स्टेबल रिलीज़	रिलीज़ कैंडिडेट	बीटा रिलीज़	ऐल्फ़ा रिलीज़
01 जुलाई, 2026	3.0.0	-	-	-

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

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

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

Kotlin

dependencies {
    val room_version = "3.0.0"

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

Groovy

dependencies {
    def room_version = "3.0.0"

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

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

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

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

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

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

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

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

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

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

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

वर्शन 3.0

वर्शन 3.0.0

01 जुलाई, 2026

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

3.0.0 वर्शन की मुख्य सुविधाएं:

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 में ये मुख्य अंतर हैं:

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

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

JS और WasmJS के साथ काम करता है
कस्टम DAO के रिटर्न टाइप
@Fts5 एनोटेशन के ज़रिए FTS5 की सुविधा
Kotlin में डिफ़ॉल्ट पैरामीटर वैल्यू के साथ काम करने की सुविधा
PrimaryKey.algorihtm प्रॉपर्टी का इस्तेमाल करके, मुख्य कुंजी जनरेट करने वाले एल्गोरिदम के बारे में जानकारी देना
'WITHOUT ROWID' टेबल बनाने की सुविधा
@Relation के साथ कंपोज़िट रिलेशनशिप कॉलम

नया पैकेज

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 को आर्ग्युमेंट के तौर पर इस्तेमाल किया गया था उन्हें भी उनके जैसे एपीआई से बदल दिया गया है. इनमें 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 और 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 के साथ RoomDatabase को कॉन्फ़िगर नहीं किया जा सकता. इसके बजाय, डेटाबेस के बिल्डर के ज़रिए CoroutineContext के साथ-साथ डिस्पैचर भी दिया जा सकता है.

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

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

वर्शन 3.0.0-rc01

17 जून, 2026

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

नई सुविधाएं

DAO क्वेरी के नतीजों में इस्तेमाल की गई डेटा क्लास में, डिफ़ॉल्ट वैल्यू वाले पैरामीटर के लिए सहायता जोड़ी गई है. ऐसी प्रॉपर्टी जो किसी कॉलम को दिखाती है और डिफ़ॉल्ट वैल्यू के साथ कंस्ट्रक्टर का हिस्सा है उसे वैकल्पिक माना जाएगा. साथ ही, नतीजे में उसके लिए कॉलम की ज़रूरत नहीं होगी. (34279a, b/70762008, b/193531601)

एपीआई में हुए बदलाव

कन्वर्ज़न के स्कोप को बेहतर तरीके से समझने और @DaoReturnTypeConverter के साथ समानता बनाए रखने के लिए, @TypeConverter का नाम बदलकर @ColumnTypeConverter कर दिया गया है. (I24420, b/438041176)
कस्टम DAO के लिए, उपलब्ध कराए गए रिटर्न टाइप के लिए एपीआई जोड़ा गया है @ProvidedDaoReturnTypeConveter. (I2a8ad, b/517485682)
PrimaryKey.autoGenerate को सही पर सेट करने पर, प्राइमरी कुंजी जनरेट करने वाले एल्गोरिदम के बारे में बताने के लिए, PrimaryKey.algorihtm प्रॉपर्टी जोड़ी गई. (I57944, b/70053837)

वर्शन 3.0.0-alpha06

03 जून, 2026

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

एपीआई में हुए बदलाव

@Entity में एक नई एनोटेशन प्रॉपर्टी जोड़ें. इसका नाम withoutRowId रखें. इसे सही पर सेट करने पर, WITHOUT ROWID विकल्प का इस्तेमाल करके, बैकिंग SQLite टेबल बनाई जाएगी. (Idb48e, b/472790803)

वर्शन 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

6 मई, 2026

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

एपीआई में हुए बदलाव

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

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

वेब टारगेट को एक ही कनेक्शन पूल का इस्तेमाल करने के लिए प्रतिबंधित करें, ताकि OPFS (b/496255935) के साथ होने वाली 'डेटाबेस लॉक किया गया' समस्याओं से बचा जा सके.
Room के बहुत बड़ा onValidateSchema जनरेट करने की वजह से होने वाली 'Method too large' गड़बड़ी को ठीक करने की कोशिश (फिर से) की गई. फ़ंक्शन को स्टेटमेंट की संख्या के आधार पर बांटा जाता है, लेकिन मेज़रमेंट सटीक नहीं होता. अगर आपको अब भी यह गड़बड़ी दिखती है, तो एनोटेशन प्रोसेसर विकल्प room.validationSplitSize का इस्तेमाल करके, यह तय किया जा सकता है कि Room कितने स्टेटमेंट को स्प्लिट के तौर पर गिनेगा. डिफ़ॉल्ट वैल्यू को फ़िलहाल 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 Context का इस्तेमाल न करता हो. Room 3.0 में कॉन्टेक्स्ट की ज़रूरत काफ़ी कम हो गई है. इसलिए, बिल्डर के लिए इसे वैकल्पिक वैल्यू बनाने से, सामान्य कोड में इन-मेमोरी डेटाबेस को ज़्यादा आसानी से बनाया जा सकता है. (I5d502, b/438041176)

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

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

वर्शन 3.0.0-alpha02

25 मार्च, 2026

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

नई सुविधाएं

FTS5 की सुविधा: @Fts5 एनोटेशन का इस्तेमाल करके, Room में FTS5 की सुविधा जोड़ी गई. इसमें FTS5 टोकनाइज़र (TOKENIZER_ASCII और TOKENIZER_TRIGRAM) के लिए नए कॉन्स्टेंट और 'detail' FTS विकल्प (FULL, COLUMN, और NONE) के लिए एक enum शामिल है. (I90934, b/146824830)
रूम पेजिंग के टारगेट: 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 रिलीज़ हो गया है.

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

Room 2.x में ये मुख्य अंतर हैं:

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

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

नया पैकेज

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

// 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 -> ... }
}

SupportSQLite रैपर

Kotlin और Coroutines First

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

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

वेब पर सहायता

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

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

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

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

@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

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

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

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