रूम का डेटाबेस अपने-आप भरने की सुविधा चुनें

कभी-कभी, हो सकता है कि आप अपने ऐप्लिकेशन को पहले से मौजूद डेटाबेस से शुरू करना चाहें का एक खास सेट लोड किया गया है. इसे डेटाबेस की पहले से जानकारी अपने-आप भरना कहा जाता है. रूम 2.2.0 और उसके बाद के वर्शन में, रूम डेटाबेस को पहले से अपने-आप भरने के लिए, एपीआई के तरीकों का इस्तेमाल किया जा सकता है डिवाइस में पहले से पैकेज की गई डेटाबेस फ़ाइल से कॉन्टेंट के साथ शुरू करते समय फ़ाइल सिस्टम.

किसी ऐप्लिकेशन ऐसेट का इस्तेमाल करके, अपने-आप जानकारी भरना

किसी जगह मौजूद, पहले से पैकेज की गई डेटाबेस फ़ाइल से रूम डेटाबेस को अपने-आप भरने के लिए अपने ऐप्लिकेशन की assets/ डायरेक्ट्री में कहीं भी, createFromAsset() को कॉल करें build() को कॉल करने से पहले, अपने RoomDatabase.Builder ऑब्जेक्ट से दिया गया तरीका:

Kotlin

Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromAsset("database/myapp.db")
    .build()

Java

Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromAsset("database/myapp.db")
    .build();

createFromAsset() तरीके में ऐसा स्ट्रिंग तर्क स्वीकार किया जाता है जिसमें assets/ डायरेक्ट्री से पहले से पैकेज की गई डेटाबेस फ़ाइल में मिलता-जुलता पाथ.

फ़ाइल सिस्टम से अपने-आप जानकारी भर लें

किसी जगह मौजूद, पहले से पैकेज की गई डेटाबेस फ़ाइल से रूम डेटाबेस को अपने-आप भरने के लिए आपके ऐप्लिकेशन की assets/ डायरेक्ट्री के अलावा, डिवाइस के फ़ाइल सिस्टम में कहीं भी, अपने RoomDatabase.Builder ऑब्जेक्ट से createFromFile() तरीके को कॉल करें build() पर कॉल करने से पहले:

Kotlin

Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromFile(File("mypath"))
    .build()

Java

Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromFile(new File("mypath"))
    .build();

createFromFile() तरीकाFile पहले से पैकेज की गई डेटाबेस फ़ाइल. रूम, असाइन की गई फ़ाइल की कॉपी बनाता है से लिंक है, तो पक्का करें कि आपके ऐप्लिकेशन के पास फ़ाइल से लिए जाते हैं.

उन माइग्रेशन को मैनेज करना जिनमें पहले से पैकेज किए गए डेटाबेस शामिल हैं

पहले से पैकेज की गई डेटाबेस फ़ाइलें भी आपके रूम के डेटाबेस के रखरखाव के तरीके में बदलाव कर सकती हैं फ़ॉलबैक माइग्रेशन. आम तौर पर, जब नुकसान पहुंचाने वाले माइग्रेशन चालू होते हैं और रूम को माइग्रेशन के बिना माइग्रेट करना होगा पाथ, रूम, डेटाबेस में सभी टेबल को दिखाता है और इनके साथ एक खाली डेटाबेस बनाता है टारगेट वर्शन के लिए तय स्कीमा. हालांकि, अगर आप किसी पहले से पैकेज की गई ऐसी डेटाबेस फ़ाइल जिसमें टारगेट वर्शन की संख्या समान हो, रूम नए फिर से बनाए गए डेटाबेस को डेटा माइग्रेट करने के बाद, पहले से पैकेज की गई डेटाबेस फ़ाइल.

रूम के डेटाबेस को माइग्रेट करने के बारे में ज़्यादा जानकारी के लिए, रूम को माइग्रेट करना डेटाबेस.

नीचे दिए सेक्शन में कुछ उदाहरण दिए गए हैं कि यह कैसे काम करता है.

उदाहरण: पहले से पैकेज किए गए डेटाबेस के साथ फ़ॉलबैक माइग्रेशन

मान लीजिए कि:

  • आपका ऐप्लिकेशन, वर्शन 3 पर रूम डेटाबेस तय करता है.
  • इस डिवाइस पर पहले से इंस्टॉल डेटाबेस इंस्टेंस, वर्शन 2 पर है.
  • पहले से पैकेज की गई एक डेटाबेस फ़ाइल मौजूद है, जो वर्शन 3 पर मौजूद है.
  • वर्शन 2 से वर्शन 3 तक कोई भी माइग्रेशन पाथ लागू नहीं है.
  • नुकसान पहुंचाने वाले माइग्रेशन चालू हैं.

Kotlin

// Database class definition declaring version 3.
@Database(version = 3)
abstract class AppDatabase : RoomDatabase() {
    ...
}

// Destructive migrations are enabled and a prepackaged database
// is provided.
Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromAsset("database/myapp.db")
    .fallbackToDestructiveMigration()
    .build()

Java

// Database class definition declaring version 3.
@Database(version = 3)
public abstract class AppDatabase extends RoomDatabase {
    ...
}

// Destructive migrations are enabled and a prepackaged database
// is provided.
Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromAsset("database/myapp.db")
    .fallbackToDestructiveMigration()
    .build();

इस स्थिति में क्या होता है:

  1. क्योंकि आपके ऐप्लिकेशन में तय किया गया डेटाबेस, वर्शन 3 और डेटाबेस डिवाइस पर पहले से ही इंस्टॉल वर्शन 2 पर है, तो माइग्रेशन ज़रूरी है.
  2. क्योंकि वर्शन 2 से वर्शन 3 तक कोई माइग्रेशन प्लान लागू नहीं किया गया है, यह माइग्रेशन, फ़ॉलबैक माइग्रेशन है.
  3. ऐसा इसलिए, क्योंकि fallbackToDestructiveMigration() बिल्डर तरीका कहा जाता है, तो फ़ॉलबैक माइग्रेशन विनाशकारी होता है. रूम, डेटाबेस को सेव करता है इंस्टॉल किया गया है.
  4. क्योंकि पहले से पैकेज की गई एक डेटाबेस फ़ाइल है जो वर्शन 3 पर मौजूद है, इसलिए रूम डेटाबेस को फिर से बनाता है और पहले से पैकेज किए गए कॉन्टेंट का इस्तेमाल करके उसे पॉप्युलेट करता है डेटाबेस फ़ाइल में सेव किया जाएगा. दूसरी ओर, अगर पहले से पैकेज की गई डेटाबेस फ़ाइल चालू थी वर्शन 2 है, तो रूम यह देखता है कि वह टारगेट वर्शन से मेल नहीं खाता और इसका इस्तेमाल, फ़ॉलबैक माइग्रेशन के हिस्से के तौर पर नहीं करेगा.

उदाहरण: पहले से पैकेज किए गए डेटाबेस की मदद से माइग्रेशन लागू किया गया

इसके बजाय, मान लीजिए कि आपका ऐप्लिकेशन वर्शन 2 से वर्शन 3:

Kotlin

// Database class definition declaring version 3.
@Database(version = 3)
abstract class AppDatabase : RoomDatabase() {
    ...
}

// Migration path definition from version 2 to version 3.
val MIGRATION_2_3 = object : Migration(2, 3) {
    override fun migrate(database: SupportSQLiteDatabase) {
        ...
    }
}

// A prepackaged database is provided.
Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromAsset("database/myapp.db")
    .addMigrations(MIGRATION_2_3)
    .build()

Java

// Database class definition declaring version 3.
@Database(version = 3)
public abstract class AppDatabase extends RoomDatabase {
    ...
}

// Migration path definition from version 2 to version 3.
static final Migration MIGRATION_2_3 = new Migration(2, 3) {
    @Override
    public void migrate(SupportSQLiteDatabase database) {
        ...
    }
};

// A prepackaged database is provided.
Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromAsset("database/myapp.db")
    .addMigrations(MIGRATION_2_3)
    .build();

इस स्थिति में क्या होता है:

  1. क्योंकि आपके ऐप्लिकेशन में तय किया गया डेटाबेस, वर्शन 3 और डेटाबेस अगर डिवाइस पर पहले से ही वर्शन 2 इंस्टॉल है, तो माइग्रेशन ज़रूरी है.
  2. क्योंकि वर्शन 2 से वर्शन 3 तक एक माइग्रेशन पाथ लागू किया गया है, डेटाबेस को अपडेट करने के लिए, रूम, तय किए गए migrate() तरीके का इस्तेमाल करता है इंस्टॉल करने के लिए, पहले से मौजूद डेटा को सुरक्षित रखें डेटाबेस. रूम, पहले से पैकेज की गई डेटाबेस फ़ाइल का इस्तेमाल नहीं करता, क्योंकि रूम फ़ॉलबैक माइग्रेशन के मामले में, पहले से पैकेज की गई डेटाबेस फ़ाइलों का इस्तेमाल करता है.

उदाहरण: पहले से पैकेज किए गए डेटाबेस की मदद से कई चरणों में माइग्रेशन

पहले से पैकेज की गई डेटाबेस फ़ाइलें उन माइग्रेशन को भी प्रभावित कर सकती हैं जिनमें एक से ज़्यादा चरण पूरे करें. नीचे दिए गए मामले पर ध्यान दें:

  • आपका ऐप्लिकेशन, वर्शन 4 पर रूम डेटाबेस तय करता है.
  • इस डिवाइस पर पहले से इंस्टॉल डेटाबेस इंस्टेंस, वर्शन 2 पर है.
  • पहले से पैकेज की गई एक डेटाबेस फ़ाइल मौजूद है, जो वर्शन 3 पर मौजूद है.
  • वर्शन 3 से वर्शन 4 तक का माइग्रेशन पाथ लागू किया गया है, लेकिन नहीं वर्शन 2 से वर्शन 3 तक.
  • नुकसान पहुंचाने वाले माइग्रेशन चालू हैं.

Kotlin

// Database class definition declaring version 4.
@Database(version = 4)
abstract class AppDatabase : RoomDatabase() {
    ...
}

// Migration path definition from version 3 to version 4.
val MIGRATION_3_4 = object : Migration(3, 4) {
    override fun migrate(database: SupportSQLiteDatabase) {
        ...
    }
}

// Destructive migrations are enabled and a prepackaged database is
// provided.
Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromAsset("database/myapp.db")
    .addMigrations(MIGRATION_3_4)
    .fallbackToDestructiveMigration()
    .build()

Java

// Database class definition declaring version 4.
@Database(version = 4)
public abstract class AppDatabase extends RoomDatabase {
    ...
}

// Migration path definition from version 3 to version 4.
static final Migration MIGRATION_3_4 = new Migration(3, 4) {
    @Override
    public void migrate(SupportSQLiteDatabase database) {
        ...
    }
};

// Destructive migrations are enabled and a prepackaged database is
// provided.
Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromAsset("database/myapp.db")
    .addMigrations(MIGRATION_3_4)
    .fallbackToDestructiveMigration()
    .build();

इस स्थिति में क्या होता है:

  1. क्योंकि आपके ऐप्लिकेशन में तय किया गया डेटाबेस और डेटाबेस डिवाइस पर पहले से ही इंस्टॉल वर्शन 2 पर है, तो माइग्रेशन ज़रूरी है.
  2. क्योंकि वर्शन 2 से वर्शन 3 तक कोई भी माइग्रेशन पाथ लागू नहीं है, यह माइग्रेशन, फ़ॉलबैक माइग्रेशन है.
  3. ऐसा इसलिए, क्योंकि fallbackToDestructiveMigration() बिल्डर तरीका कहा जाता है, तो फ़ॉलबैक माइग्रेशन विनाशकारी होता है. रूम, डेटाबेस को सेव करता है इंस्टेंस.
  4. क्योंकि पहले से पैकेज की गई एक डेटाबेस फ़ाइल है जो वर्शन 3 पर मौजूद है, इसलिए रूम डेटाबेस को फिर से बनाता है और पहले से पैकेज किए गए कॉन्टेंट का इस्तेमाल करके उसे पॉप्युलेट करता है डेटाबेस फ़ाइल में सेव किया जाएगा.
  5. डिवाइस पर इंस्टॉल किया गया डेटाबेस अब वर्शन 3 पर है. क्योंकि यह आपके ऐप्लिकेशन में बताए गए वर्शन से अब भी कम है, तो एक और माइग्रेशन ज़रूरी है.
  6. वर्शन 3 से वर्शन 4 तक का माइग्रेशन पाथ लागू किया गया है, इसलिए डेटाबेस को अपडेट करने के लिए, रूम, तय किए गए migrate() तरीके का इस्तेमाल करता है इंस्टेंस 4 पर कॉपी करता है, ताकि कॉपी किया गया डेटा सुरक्षित रहे पहले से पैकेज की गई डेटाबेस फ़ाइल में एक्सपोर्ट किया जा सकता है.

अन्य संसाधन

रूम डेटाबेस को अपने-आप भरने के बारे में ज़्यादा जानने के लिए, यहां दी गई अतिरिक्त जानकारी देखें संसाधन.

वीडियो

ब्लॉग

पीछे जाएं
डेटाबेस में व्यू बनाना
आगे बढ़ें
अपने डेटाबेस को माइग्रेट करें