আপনার রুম ডাটাবেস প্রস্তুত করুন

আপনি যদি চান আপনার অ্যাপটি একটি নির্দিষ্ট ডেটাসেট দিয়ে আগে থেকেই লোড করা একটি ডাটাবেস দিয়ে চালু হোক, তাহলে আপনি ডাটাবেসটি প্রি-পপুলেট করতে পারেন। Room-এ, আপনি ডিভাইসের ফাইল সিস্টেমে থাকা একটি প্রি-প্যাকেজড ডাটাবেস ফাইল থেকে ডেটা নিয়ে অ্যাপটি চালু করার সময় ডাটাবেসটি প্রি-পপুলেট করতে এপিআই (API) ব্যবহার করতে পারেন।

একটি অ্যাপ অ্যাসেট থেকে আগে থেকে পূরণ করুন

আপনার অ্যাপের assets/ ডিরেক্টরির যেকোনো স্থানে অবস্থিত একটি পূর্ব-প্যাকেজ করা ডেটাবেস ফাইল থেকে Room ডেটাবেসটি আগে থেকে পূরণ করতে, build কল করার আগে আপনার RoomDatabase.Builder অবজেক্ট থেকে createFromAsset ফাংশনটি কল করুন:

Room.databaseBuilder<AppDatabase>(appContext, "sample.db")
    .createFromAsset("database/myapp.db")
    .build()
PrepopulateSnippets.kt

createFromAsset ফাংশনটি একটি স্ট্রিং আর্গুমেন্ট গ্রহণ করে, যাতে assets/ ডিরেক্টরি থেকে প্রি-প্যাকেজড ডাটাবেস ফাইলের একটি রিলেটিভ পাথ থাকে।

ফাইল সিস্টেম থেকে আগে থেকেই পূরণ করুন

আপনার অ্যাপের assets/ ডিরেক্টরি ছাড়া ডিভাইসের ফাইল সিস্টেমের যেকোনো স্থানে অবস্থিত একটি পূর্ব-প্যাকেজ করা ডেটাবেস ফাইল থেকে Room ডেটাবেসকে আগে থেকে পূরণ করতে, build কল করার আগে আপনার RoomDatabase.Builder অবজেক্ট থেকে createFromFile ফাংশনটি কল করুন:

Room.databaseBuilder<AppDatabase>(appContext, "sample.db")
    .createFromFile(File("mypath"))
    .build()
PrepopulateSnippets.kt

createFromFile ফাংশনটি আগে থেকে তৈরি করা ডাটাবেস ফাইলের জন্য একটি File আর্গুমেন্ট গ্রহণ করে। `Room` নির্দিষ্ট ফাইলটি সরাসরি না খুলে সেটির একটি অনুলিপি তৈরি করে, তাই নিশ্চিত করুন যে ফাইলটিতে আপনার অ্যাপের পড়ার অনুমতি (read permissions) আছে।

প্রি-প্যাকেজড ডেটাবেস অন্তর্ভুক্ত মাইগ্রেশনগুলি পরিচালনা করুন

প্রি-প্যাকেজড ডাটাবেস ফাইলগুলো আপনার Room ডাটাবেসের ফলব্যাক মাইগ্রেশন পরিচালনার পদ্ধতিও পরিবর্তন করতে পারে। সাধারণত, যখন ডেস্ট্রাকটিভ মাইগ্রেশন সক্রিয় থাকে এবং Room-কে কোনো মাইগ্রেশন পাথ ছাড়া মাইগ্রেশন করতে হয়, তখন Room ডাটাবেসের সমস্ত টেবিল ড্রপ করে দেয় এবং টার্গেট ভার্সনের জন্য নির্দিষ্ট স্কিমাসহ একটি খালি ডাটাবেস তৈরি করে। তবে, যদি আপনি টার্গেট ভার্সনের সমান নম্বরের একটি প্রি-প্যাকেজড ডাটাবেস ফাইল অন্তর্ভুক্ত করেন, তাহলে ডেস্ট্রাকটিভ মাইগ্রেশন সম্পন্ন করার পর Room নতুন করে তৈরি করা ডাটাবেসটিকে সেই প্রি-প্যাকেজড ডাটাবেস ফাইলের বিষয়বস্তু দিয়ে পূর্ণ করে দেয়।

রুম ডাটাবেস মাইগ্রেশন সম্পর্কে আরও তথ্যের জন্য, আপনার রুম ডাটাবেস মাইগ্রেট করুন দেখুন।

নিম্নলিখিত বিভাগগুলিতে বাস্তবে এটি কীভাবে কাজ করে তার কয়েকটি উদাহরণ উপস্থাপন করা হয়েছে।

উদাহরণ: পূর্ব-প্যাকেজ করা ডাটাবেস সহ ফলব্যাক মাইগ্রেশন

নিম্নলিখিত বিষয়গুলো বিবেচনা করুন:

• আপনার অ্যাপের সংস্করণ ৩-এ একটি রুম ডেটাবেস সংজ্ঞায়িত করা হয়েছে।
• ডিভাইসটিতে আগে থেকে ইনস্টল করা ডাটাবেস ইনস্ট্যান্সটি ভার্সন ২-এ রয়েছে।
• একটি পূর্ব-প্রস্তুত ডাটাবেস ফাইল আছে, যেটি ভার্সন ৩-এ রয়েছে।
• ভার্সন ২ থেকে ভার্সন ৩-এ স্থানান্তরের কোনো বাস্তবায়িত পথ নেই।
• ধ্বংসাত্মক স্থানান্তর সক্রিয় করা হয়েছে।

// Database class definition declaring version 3.
@Database(entities = [SampleEntity::class], version = 3)
abstract class FallbackAppDatabase : RoomDatabase() {
    // ...
}

fun createFallbackDb(appContext: Context) {
    Room.databaseBuilder<FallbackAppDatabase>(appContext, "sample.db")
        .createFromAsset("database/myapp.db")
        .fallbackToDestructiveMigration()
        .build()
}
PrepopulateSnippets.kt

এই পরিস্থিতিতে যা ঘটে তা হলো:

1. যেহেতু আপনার অ্যাপে সংজ্ঞায়িত ডাটাবেসটি ভার্সন ৩ এবং ডিভাইসে আগে থেকে ইনস্টল করা ডাটাবেস ইনস্ট্যান্সটি ভার্সন ২, তাই একটি মাইগ্রেশন প্রয়োজন।
2. যেহেতু ভার্সন ২ থেকে ভার্সন ৩-এ স্থানান্তরের কোনো বাস্তবায়িত পরিকল্পনা নেই, তাই এই স্থানান্তরটি একটি ফলব্যাক মাইগ্রেশন।
3. যেহেতু আপনি fallbackToDestructiveMigration বিল্ডার ফাংশনটি কল করেন, তাই ফলব্যাক মাইগ্রেশনটি ধ্বংসাত্মক হয়। Room ডিভাইসটিতে ইনস্টল করা ডাটাবেস ইনস্ট্যান্সটি ড্রপ করে দেয়।
4. যেহেতু ভার্সন ৩-এর একটি প্রি-প্যাকেজড ডাটাবেস ফাইল রয়েছে, তাই Room ডাটাবেসটি পুনরায় তৈরি করে এবং সেই প্রি-প্যাকেজড ডাটাবেস ফাইলের বিষয়বস্তু ব্যবহার করে এটিতে ডেটা যুক্ত করে। যদি আপনার প্রি-প্যাকেজড ডাটাবেস ফাইলটি ভার্সন ২-এর হয়, তাহলে Room এটিকে টার্গেট ভার্সনের সাথে অমিল হিসেবে বিবেচনা করে এবং ফলব্যাক মাইগ্রেশনের জন্য এটি ব্যবহার করে না।

উদাহরণ: একটি পূর্ব-প্যাকেজ করা ডাটাবেস দিয়ে মাইগ্রেশন বাস্তবায়ন করা হয়েছে।

এর পরিবর্তে ধরুন যে আপনার অ্যাপটি ভার্সন ২ থেকে ভার্সন ৩-এ স্থানান্তরের একটি পথ বাস্তবায়ন করে:

// Database class definition declaring version 3.
@Database(entities = [SampleEntity::class], version = 3)
abstract class ImplementedAppDatabase : RoomDatabase() {
    // ...
}

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

fun createImplementedDb(appContext: Context) {
    Room.databaseBuilder<ImplementedAppDatabase>(appContext, "sample.db")
        .createFromAsset("database/myapp.db")
        .addMigrations(MIGRATION_2_3)
        .build()
}
PrepopulateSnippets.kt

এই পরিস্থিতিতে যা ঘটে তা হলো:

1. যেহেতু আপনার অ্যাপে সংজ্ঞায়িত ডাটাবেসটি ভার্সন ৩ এবং ডিভাইসে আগে থেকে ইনস্টল করা ডাটাবেসটি ভার্সন ২, তাই মাইগ্রেশন করা প্রয়োজন।
2. যেহেতু ভার্সন ২ থেকে ভার্সন ৩-এ স্থানান্তরের একটি কার্যকর পথ রয়েছে, তাই Room ডিভাইসে থাকা ডাটাবেস ইনস্ট্যান্সটিকে ভার্সন ৩-এ আপডেট করার জন্য সংজ্ঞায়িত migrate ফাংশনটি চালায় এবং ডাটাবেসে আগে থেকে থাকা ডেটা অক্ষুণ্ণ রাখে। Room আগে থেকে তৈরি ডাটাবেস ফাইলটি ব্যবহার করে না, কারণ Room শুধুমাত্র ফলব্যাক মাইগ্রেশনের ক্ষেত্রেই আগে থেকে তৈরি ডাটাবেস ফাইল ব্যবহার করে।

উদাহরণ: পূর্ব-প্যাকেজ করা ডাটাবেস সহ বহু-ধাপের মাইগ্রেশন

পূর্ব-প্যাকেজ করা ডাটাবেস ফাইলগুলোও একাধিক ধাপের মাইগ্রেশনকে প্রভাবিত করতে পারে। নিম্নলিখিত পরিস্থিতিটি বিবেচনা করুন:

• আপনার অ্যাপটি সংস্করণ ৪-এ একটি রুম ডেটাবেস নির্ধারণ করে।
• ডিভাইসটিতে আগে থেকে ইনস্টল করা ডাটাবেস ইনস্ট্যান্সটি ভার্সন ২-এ রয়েছে।
• একটি পূর্ব-প্রস্তুত ডাটাবেস ফাইল আছে, যেটি ভার্সন ৩-এ রয়েছে।
• ভার্সন ৩ থেকে ভার্সন ৪-এ যাওয়ার জন্য একটি মাইগ্রেশন পথ চালু আছে, কিন্তু ভার্সন ২ থেকে ভার্সন ৩-এ যাওয়ার জন্য নেই।
• ধ্বংসাত্মক স্থানান্তর সক্রিয় করা হয়েছে।

// Database class definition declaring version 4.
@Database(entities = [SampleEntity::class], version = 4)
abstract class MultiStepAppDatabase : RoomDatabase() {
    // ...
}

val MIGRATION_3_4 = object : Migration(3, 4) {
    override suspend fun migrate(connection: SQLiteConnection) {
        // ...
    }
}

fun createMultiStepDb(appContext: Context) {
    Room.databaseBuilder<MultiStepAppDatabase>(appContext, "sample.db")
        .createFromAsset("database/myapp.db")
        .addMigrations(MIGRATION_3_4)
        .fallbackToDestructiveMigration()
        .build()
}
PrepopulateSnippets.kt

এই পরিস্থিতিতে যা ঘটে তা হলো:

1. যেহেতু আপনার অ্যাপে সংজ্ঞায়িত ডাটাবেসটি ভার্সন ৪-এর এবং ডিভাইসে আগে থেকে ইনস্টল করা ডাটাবেস ইনস্ট্যান্সটি ভার্সন ২-এর, তাই একটি মাইগ্রেশন প্রয়োজন।
2. যেহেতু ভার্সন ২ থেকে ভার্সন ৩-এ যাওয়ার জন্য কোনো বাস্তবায়িত মাইগ্রেশন পথ নেই, তাই এই মাইগ্রেশনটি একটি ফলব্যাক মাইগ্রেশন।
3. যেহেতু আপনি fallbackToDestructiveMigration বিল্ডার ফাংশনটি কল করেন, তাই ফলব্যাক মাইগ্রেশনটি ধ্বংসাত্মক হয়। Room ডিভাইসটিতে থাকা ডাটাবেস ইনস্ট্যান্সটি ড্রপ করে দেয়।
4. যেহেতু ভার্সন ৩-এর একটি প্রি-প্যাকেজড ডেটাবেস ফাইল রয়েছে, তাই Room সেই প্রি-প্যাকেজড ডেটাবেস ফাইলের বিষয়বস্তু ব্যবহার করে ডেটাবেসটি পুনরায় তৈরি করে এবং ডেটা দিয়ে পূর্ণ করে।
5. ডিভাইসে ইনস্টল করা ডাটাবেসটি এখন ভার্সন ৩-এ আছে। যেহেতু এটি এখনও আপনার অ্যাপে নির্ধারিত ভার্সনের চেয়ে নিম্ন, তাই আরেকটি মাইগ্রেশন প্রয়োজন।
6. যেহেতু ভার্সন ৩ থেকে ভার্সন ৪-এ স্থানান্তরের একটি প্রক্রিয়া চালু আছে, তাই Room ডিভাইসের ডাটাবেস ইনস্ট্যান্সটিকে ভার্সন ৪-এ আপডেট করার জন্য নির্ধারিত migrate ফাংশনটি চালায় এবং ভার্সন ৩-এর প্রি-প্যাকেজড ডাটাবেস ফাইল থেকে কপি করা ডেটা অক্ষুণ্ণ রাখে।