Drift Database Modularity: Problem with Too Many Imports

[jogo81]

Hello everyone,

I'm working on a large Flutter project that is heavily modularized. Each feature uses its own database tables and DAOs. However, my central database class in Drift needs to define all the tables and DAOs in the annotation, leading to a large number of imports and making modularity difficult. Here is an example of how it currently looks:

import 'dart:async';

import 'package:drift/drift.dart';
import 'package:drift/native.dart';

import 'feature1.dart';
import 'feature2.dart';
// Many more imports...

part 'database.g.dart';

@DriftDatabase(
  tables: [
    Feature1Table,
    Feature2Table,
    // Many more tables...
  ],
  daos: [
    Feature1Dao,
    Feature2Dao,
    // Many more DAOs...
  ],
)
class AppDatabase extends _$AppDatabase {
  // Implementation...
}

Problem:

The imports from the many features make the file unwieldy and go against the goal of modularity. How can we structure the database in a way that remains modular and easy to manage?

How have you solved this problem in your projects? Are there best practices or design patterns that promote modularity in Drift databases without overloading the central database class?

Best regards!

[simolus3]

Thank you for starting this discussion!

The imports from the many features make the file unwieldy and go against the goal of modularity. How can we structure the database in a way that remains modular and easy to manage?

Fundamentally, the main database class needs to know about all the tables involved to generate the default migrations creating all tables. Knowing things like references between tables is also relevant for updating query streams in some cases.
However, that limitation should only be a concern for code generated by drift - as a drift user, it shouldn't be (as) visible to you. Drift offers modular code generation as an alternative to the monolithic build generating everything into a single part file, which can help a lot.
When enabling modular code generation, drift will emit an independent file (meaning that it can have its own imports) for each file containing a database, dao or table. You also don't have to explicitly list all tables or DAOs anymore, you can just include them like this:

// feature1.dart
import 'package:drift/drift.dart';
import 'feature1.drift.dart';

class Users extends Table {
  IntColumn get id => integer().autoIncrement()();
  TextColumn get name => text()();
}

// Note that this doesn't have to reference the exact database class:
@DriftAccessor(tables: [Users])
class UsersDao extends DatabaseAccessor<GeneratedDatabase> with $UsersDaoMixin {
  UsersDao(super.attachedDatabase);

  Future<List<User>> get all => users.all().get();
}

import 'package:drift/drift.dart';
import 'database.drift.dart';

@DriftDatabase(include: {'feature1.dart'})
class AppDatabase extends $AppDatabase {

You can then continue to use AppDatabase like before, except that you would no longer get automated references to the DAO classes - but you can create them with UsersDao(yourDatabase), which works well together with dependency injection frameworks.

It's worth noting that modular code generation has originally been designed with drift files in mind. It also works much better with them by automatically creating DAOs where necessary and also adding implicit getters. At the moment, drift also prints an ugly warning when using include to add Dart-defined tables (introduced due to #2462 (comment)). We can probably improve modular code generation by disabling that warning for modular builds and automatically adding getters for DAO classes added through include.