Code generation for Drift tables and DAOs for an imported package from a separate repository

[Darius1323]

Hi, I was trying to implement a modular structure for an application that I am building for my internship assignment and I want to achieve reusable modules, so the modules can be imported in other future applications as packages and added to their persistence layer.

Currently, each module has it's own pubspec.yaml and build.yaml to generate the necessary code for the tables and DAOs of a module. However, when I import a module within an app that needs to use that module I get a warning regarding "build_resolvers"

------
[WARNING] build_resolvers:transitive_digests on package:actfact_timesheets/actfact_timesheets.dart:
Unable to read asset, could not compute transitive deps: actfact_timesheets|lib/src/infrastructure/local/timesheet_dao.drift.dart
------

I am in a bit of doubt if it's possible to generate the code for the imported modules that have drift tables and daos within the working app, I tried to configure the build.yaml but no result. I would just push the generated code from the module itself but as I know pushing generated code to remote repository isn't really a good practice.

Does anyone know a workaround this?

in order to make modules reusable I have defined an abstract class that needs to be implemented by each module. The abstractions are located in a separate package to prevent circular dependency.

abstract class AbstractDatabase extends GeneratedDatabase {
  AbstractDatabase(QueryExecutor e) : super(e);
}

Then the DAOs will use that abstract class 
@DriftAccessor(tables: [Timesheets])
class TimesheetDao extends DatabaseAccessor<AbstractDatabase>
    with $TimesheetDaoMixin {
  TimesheetDao(super.attachedDatabase);
}

@DataClassName('TimesheetRecord')
class Timesheets extends Table {
  IntColumn get id => integer().autoIncrement()();
  TextColumn get name => text().nullable()();
  DateTimeColumn get timestamp => dateTime()();
}

When a future app needs a module like a Timesheet, it will just import that one as a package and add it to their Drift Database to have all the tables before building the database schema.

@DriftDatabase(tables: [Timesheets], daos: [TimesheetDao])
class LocalDatabase extends AbstractDatabase with $AppDatabase {
  LocalDatabase(super.e);

  @override
  int get schemaVersion => 1;
  
  @override
  // TODO: implement allTables
  Iterable<TableInfo<Table, dynamic>> get allTables => throw UnimplementedError();
}

[simolus3]

It's not possible with build_runner to generate source files outside of the package you're running build_runner on. The issue about transitive assets sounds like a potential bug in the build system itself, or is the problem that the generated file won't exist because build_runner can't generate code for other packages? I think the transitive assets thing is mostly an optimization though, it shouldn't break your build.

I would just push the generated code from the module itself but as I know pushing generated code to remote repository isn't really a good practice.

To be fair, it's not terrible IMO. If you have things like json serialization with json_serializable in these remote packages, you'd probably want to include that in source-control as well.

I have an example here that uses multiple packages with shared code. I don't get the warning about transitive digests there, and the build setup is not that special. Are you using the modular builder from drift?

[Darius1323]

Are you using the modular builder from drift?

Yes, I tried the modular builder for modules and also the app that imports the modules. I think then that the only option left is to push the generated code. Then, perhaps I would need to automate this process through a pipeline to ensure that always the changes from modules end up generated, which I think it's good. But I always thought that it's better to generate the necessary code when it will be actually used to avoid cluttering and also potential human error in generating the code but since it can be automated it won't happen.

However, I don't know if this will help me reach modularity in the way in which I can reuse modules in separate app repositories. The daos of a module needs to know the possible database inside the DatabaseAccessor which expects a GeneratedDatabase which is generate by the app that is initializing the database and includes the Tables and DAOs of a imported module. If I generate the code within a module and push it it won't know anything about the concrete database and I don't know how it could possibly access that.

I tried to make a abstract class called AbstractDatabase which extends the GeneratedDatabase and use that for daos within modules as a way to provide a potential database that can be for that dao, and then implement that AbstractDatabase to a concrete one within a application that requires a certain module. However, I don't know if just adding the tables and daos within the @DriftDatabase annotation would solve the generation problem for that since then the database will know about the daos and tables, however I will run into another problem which is using the generated close which also extends GeneratedDatabase.

I hope my concern makes sense and I hope there is a solution for it.

[simolus3]

The daos of a module needs to know the possible database inside the DatabaseAccessor which expects a GeneratedDatabase which is generate by the app that is initializing the database and includes the Tables and DAOs of a imported module.

It's worth nothing that you don't have to reference the actual database class being used in the DAOs. Especially when using modular code generation, drift is able to decouple them entirely.

So you can define your DAOs as extends DatabaseAccessor<GeneratedDatabase> and it should work. You'll still have access to the tables you've referenced in the @DriftAccessor annotation.