Floor — یہ کیا ہے، Flutter میں SQLite پر ORM

Floor کیا ہے؟

Floor SQLite پر بنائی گئی Flutter اور Dart کے لیے ایک ORM لائبریری ہے۔ یہ اینٹیٹیز (Entity)، Data Access Objects (DAO) اور ڈیٹا بیس (Database) کو بیان کرنے کے لیے اینوٹیشن استعمال کرتی ہے۔ کوڈ جنریشن build_runner اور floor_generator کے ذریعے کی جاتی ہے — کمپائلر DAO نفاذات اور ایک مینیجنگ ڈیٹا بیس کلاس بناتا ہے۔ خام sqflite کے برعکس، Floor ٹائپ ریفلیکشن کے ذریعے کالم کو خود بخود Entity فیلڈز میں میپ کرکے ResultSet سے Dart آبجیکٹس میں دستی تبدیلی کی ضرورت کو مکمل طور پر ختم کرتا ہے۔

Floor Android ڈویلپرز کو Room سے واقف Repository + DAO پیٹرن کی پیروی کرتا ہے۔ ہر ٹیبل کو @Entity اینوٹیشن والی Dart کلاس سے ظاہر کیا جاتا ہے، SQL سوالات کو @dao اینوٹیشن والے انٹرفیس میں گروپ کیا جاتا ہے، اور ڈیٹا بیس کو @Database والی ایک تجریدی کلاس میں جمع کیا جاتا ہے۔ یہ نقطہ نظر ڈیٹا ماڈل کو سوالات کی منطق سے سختی سے الگ کرتا ہے۔

Flutter Pulse (2023) کے مطابق، 28% Flutter پروجیکٹس میں Floor کا انتخاب کیا جاتا ہے جنہیں مقامی ڈیٹا بیس کی ضرورت ہوتی ہے۔ اسے منتخب کرنے کی اہم وجوہات SQL سے واقفیت (نیا سوالات کی زبان سیکھنے کی ضرورت نہیں) اور کمپائل ٹائم سوالات کی جانچ ہیں۔ اس کے علاوہ، Floor پڑھنے کے قابل کوڈ جنریٹ کرتا ہے جو کسٹم DSL والے مزید تجریدی ORM کے مقابلے میں ڈیبگ کرنا آسان ہے، جو ٹیم میں نئے ڈویلپرز کے لیے داخلے کی راہ میں رکاوٹ کو کم کرتا ہے۔

Floor آرکیٹیکچر

Floor تین پرتوں پر مشتمل ہے: Entity (ٹیبل ماڈل)، DAO (سوالات کا انٹرفیس) اور Database (داخلی نقطہ)۔ جنریٹر فیلڈ میپنگ کے لیے _$_Entity نفاذات اور SQL پر عمل درآمد کے لیے _$_Dao بناتا ہے۔ جب Entity یا DAO تبدیل ہوتا ہے، build_runner کو دوبارہ شروع کرنا کافی ہے — کوڈ خود بخود اپ ڈیٹ ہو جاتا ہے۔ اسکیما ورژن کے درمیان منتقلی کے لیے، Floor ترتیب وار ورژن نمبر استعمال کرتا ہے، جو صارفین کے آلات پر ایپ اپ ڈیٹ کرتے وقت ڈیٹا کی سالمیت کو یقینی بناتا ہے۔

Flutter میں Floor کیسے کام کرتا ہے؟

Floor پلیٹ فارم بلڈز کے لیے sqflite پیکیج اور ڈیسک ٹاپ اور ویب کے لیے sqlite3 کے ذریعے SQLite استعمال کرتا ہے۔ جب ایپ شروع ہوتی ہے، Floor SQLite فائل بناتا یا کھولتا ہے، منتقلیاں لاگو کرتا ہے اور سوالات پر عمل درآمد کے لیے DAO طریقے تیار کرتا ہے۔ تمام کارروائیاں Future اور Stream کے ذریعے غیر متزامن طور پر انجام دی جاتی ہیں۔

Floor میں کوڈ جنریشن اس طرح کام کرتی ہے: پارسر سورس فائلوں سے اینوٹیشن پڑھتا ہے، ماڈلز اور سوالات کا AST (تجریڈ نحوی درخت) بناتا ہے، پھر _$ سابقہ کے ساتھ Dart فائلیں جنریٹ کرتا ہے۔ جنریٹڈ کوڈ میں ResultSet → Entity میپر اور اس کے برعکس شامل ہیں۔

تھریڈ سیفٹی

Floor ایک ہی isolate میں SQLite کے ساتھ کام کرتا ہے۔ تمام سوالات غیر متزامن طور پر انجام دیے جاتے ہیں، لیکن بیک وقت تحریریں SQLite سطح پر مقفل ہوتی ہیں۔ لین دین کے لیے، @transaction اینوٹیشن استعمال کیا جاتا ہے، جو سوالات کے گروپ کی ایٹمیٹ اور غلطی پر رول بیک کی ضمانت دیتا ہے۔

Floor vs Drift: Flutter کے لیے ORM موازنہ

Floor اور Drift دونوں SQLite پر ORM ہیں، لیکن وہ فلسفے میں مختلف ہیں۔ Floor Android کے Room کے قریب ہے، Drift بلٹ ان Stream API اور SQL فائلوں کے ذریعے سوالات کی کمپائلیشن کے ساتھ زیادہ ری ایکٹو ہے۔ ان کے درمیان انتخاب ٹیم کے تجربے اور مطلوبہ ری ایکٹیویٹی پر منحصر ہے۔

Floor کب منتخب کریں

Floor ان ٹیموں کے لیے انتخاب ہے جو پہلے سے SQL اور Android Room سے واقف ہیں۔ اگر ڈویلپر دستی طور پر SQL سوالات لکھنے کے عادی ہیں اور SQLite پر کم سے کم ریپر چاہتے ہیں — Floor نیا DSL سیکھے بغیر ٹائپنگ فراہم کرتا ہے۔ یہ ڈیبگ کرنا بھی آسان ہے کیونکہ جنریٹڈ کوڈ پڑھنے کے قابل اور پیش گوئی کے قابل ہے۔

Drift کب بہتر ہے

Drift زیادہ طاقتور ری ایکٹیویٹی پیش کرتا ہے اور زیادہ پلیٹ فارمز کو سپورٹ کرتا ہے۔ اگر ایپ UI اپ ڈیٹس کے لیے Stream کو فعال طور پر استعمال کرتی ہے، JOIN اور ذیلی سوالات کے ساتھ پیچیدہ سوالات کی ضرورت ہوتی ہے یا ویب کو نشانہ بناتی ہے — Drift بہتر ہے۔ تاہم، اس کے اپنے DSL کو سیکھنے کی ضرورت کی وجہ سے داخلے کی راہ میں رکاوٹ زیادہ ہے۔

Floor کے ساتھ کوڈ مثالیں

Floor اینوٹیشن کے ارد گرد بنایا گیا ہے۔ نیچے ٹاسک لسٹ ایپ کے لیے Entity، DAO اور Database کی مکمل مثال دی گئی ہے۔ build_runner چلانے کے بعد، جنریٹڈ کلاسز استعمال کے لیے تیار ہیں۔

Entity اور DAO کی تعریف

TaskEntity کلاس @Entity اینوٹیشن کے ساتھ task ٹیبل پر میپ ہوتی ہے۔ @primaryKey والا فیلڈ بنیادی کلید بن جاتا ہے۔ TaskDao انٹرفیس میں ٹیبل آپریشنز کے لیے طریقے ہیں — ہر طریقہ @Query، @Insert، @Update یا @Delete سے اینوٹیٹڈ ہے۔

@entity
class TaskEntity {
    @PrimaryKey(autoGenerate: true)
    final int id;
    final String title;
    final bool isCompleted;
    final int priority;

    TaskEntity({this.id, required this.title,
        this.isCompleted = false, this.priority = 0});
}

@dao
abstract class TaskDao {
    @Query('SELECT * FROM TaskEntity ORDER BY priority DESC')
    Future<List<TaskEntity>> getAllTasks();

    @Insert
    Future<int> insertTask(TaskEntity task);

    @Update
    Future<void> updateTask(TaskEntity task);

    @Query('SELECT * FROM TaskEntity WHERE isCompleted = :status')
    Stream<List<TaskEntity>> watchTasks(bool status);
}

ڈیٹا بیس کی ابتدا

@Database اینوٹیشن والی ایک تجریدی کلاس Entity اور DAO کو جوڑتی ہے۔ databaseBuilder طریقہ ڈیٹا بیس کی مثال بناتا ہے۔ build کو کال کرنے کے بعد، ڈیٹا بیس تیار ہے: Floor SQLite فائل کھولتا ہے، منتقلیاں لاگو کرتا ہے اور کام کے لیے DAO لوٹاتا ہے۔

@Database(version: 1, entities: [TaskEntity])
abstract class AppDatabase extends FloorDatabase {
    TaskDao get taskDao;
}

// استعمال
final database = await $FloorAppDatabase.databaseBuilder('app.db').build();
final taskDao = database.taskDao;
final tasks = await taskDao.getAllTasks();

Stream کے ذریعے ری ایکٹیو سوالات

Floor DAO طریقوں سے Stream واپس کرنے کی حمایت کرتا ہے۔ ٹیبل میں کسی بھی تبدیلی پر، Stream ایک نئی فہرست جاری کرتا ہے۔ یہ Flutter میں StreamBuilder کے ساتھ ضم ہوتا ہے — جب ریکارڈ شامل، تبدیل یا حذف کیے جاتے ہیں تو UI خود بخود اپ ڈیٹ ہو جاتا ہے۔

@Query('SELECT * FROM TaskEntity ORDER BY priority DESC')
Stream<List<TaskEntity>> watchAllTasks();

// Flutter widget میں
StreamBuilder<List<TaskEntity>>(
    stream: taskDao.watchAllTasks(),
    builder: (context, snapshot) {
        final tasks = snapshot.data ?? [];
        return ListView.builder(
            itemCount: tasks.length,
            itemBuilder: (_, i) => TaskTile(tasks[i]),
        );
    },
)

Floor میں منتقلی اور ورژننگ

Floor @Database اینوٹیشن میں version پیرامیٹر کے ذریعے ڈیٹا بیس ورژننگ کو سپورٹ کرتا ہے۔ جب Entity تبدیل ہوتا ہے (فیلڈز شامل یا ہٹانا)، آپ کو ورژن بڑھانے اور منتقلی شامل کرنے کی ضرورت ہے۔ منتقلی ایک Dart فنکشن ہے جو لین دین وصول کرتا ہے اور ALTER TABLE SQL سوالات پر عمل درآمد کرتا ہے۔

منتقلی کی مثال

فرض کریں ورژن 2 میں ہم نے TaskEntity میں dueDate فیلڈ شامل کیا۔ منتقلی ALTER TABLE SQL سوال کے ذریعے کی جاتی ہے۔ اگر منتقلی متعین نہیں کی گئی، Floor MigrationStrategy کو کال کرتا ہے جہاں آپ فال بیک سیٹ کر سکتے ہیں (مثال کے طور پر، ڈیٹا کے نقصان کے ساتھ ٹیبل کو دوبارہ بنانا)۔

Floor سوالات کی جانچ

Floor بلٹ ان موک فریم ورک فراہم نہیں کرتا، لیکن ڈیٹا بیس کو ٹیسٹ میں آسانی سے تبدیل کیا جا سکتا ہے۔ inMemoryDatabaseBuilder بنائیں — یہ اسکیما میں پروڈکشن جیسی میموری میں SQLite ڈیٹا بیس بناتا ہے۔ ہر ٹیسٹ کے بعد، ٹیسٹ منظرناموں کو الگ کرنے کے لیے deleteDatabase کے ذریعے ڈیٹا صاف کریں۔

Floor میں لین دین اور بیچ آپریشنز

Floor DAO طریقوں پر @transaction اینوٹیشن کے ذریعے لین دین کو سپورٹ کرتا ہے۔ لین دین کے اندر، متعدد سوالات غلطی پر رول بیک گارنٹی کے ساتھ ترتیب وار انجام دیے جاتے ہیں۔ List پیرامیٹر کے ساتھ @Insert کے ذریعے بیچ اندراج ایک کال میں متعدد ریکارڈ داخل کرنے کو بہتر بناتا ہے — یہ لوپ میں ایک وقت میں ایک ریکارڈ داخل کرنے سے کئی گنا تیز ہے۔ بڑی کارروائیوں کے لیے، 100–200 ریکارڈ کے بیچ اندراج استعمال کریں: محدود وسائل والے موبائل آلات پر عملدرآمد کی رفتار اور RAM کی کھپت کے درمیان یہ بہترین توازن ہے۔

final migration1to2 = Migration(1, 2, (database) async {
    await database.execute(
        'ALTER TABLE TaskEntity ADD COLUMN dueDate TEXT'
    );
});

final database = await $FloorAppDatabase.databaseBuilder('app.db')
    .addMigrations([migration1to2])
    .build();