Don't generate tables for abstract class derivatives of Table

[Adam-Langley]

I have common table schemas used across many tables (and other purposes) - hence I would like to use the following pattern:

abstract class MyCommonTable extends Table
{
}

class MyConcreteTable extends MyCommonTable
{
}

This would work fine - however, when the build_runner executes, drift says "Due to includes added to the database, the following Dart tables which have not been added to tables or views will be included in this database: MyCommonTable" - even though I have marked it as abstract.

Can we please have drift exclude abstract classes from code-gen, but of course, allow concrete implementations to inherit their properties (i.e, the generator should generate all fields defined in MyCommonTable, for any concrete derivative).

Thank you!

[simolus3]

This would be breaking, but I'm in favor of a build option disabling abstract tables to be considered as standalone tables.

However, you also mentioned that some of your tables are defined as mixins? It seems a bit odd to not consider abstract classes while also supporting mixins as standalone table classes (or are they also just used to contain shared column definitions)?

[Adam-Langley]

Hi @simolus3

Thanks for taking a look at this. Agreed - official support of mixins would be great. I'm already using mixins, and when I first wrote the db layer, I do recall having to jump through many hoops to get it to work, and still suffering many warnings. I had to explicitly reorder the sequence in which the generators would run to make sure everything worked. I have another issue open which would be related #3162.

My actual use-case is this:

1. build script downloads swagger file
2. I have classes which extend from Table, are annotated with a custom annotation (i.e "GenerateTableFromSwagger('nameOfSwaggerEntityContract')", and "mixin" a class which doesn't exist yet (generated next)
3. My custom generator will find these classes, correlate them with an entity definition in swagger json, then generate the necessary mixin for each with all the properties.
4. The drift generator runs, and does what it does best

I've hit some issues with the mixin approach which I tried to solve using an abstract base class instead (hence this ticket). But, if mixins were fully supported, that would be awesome too

Thank you!

[FMorschel]

In my project, I have several tables with at least two common primary keys (PKs). These tables extend a simple abstract table class (lets call it AT) containing these columns.

In my DAOs, I consistently implement a set of specific, similar methods across these tables. To streamline this, I created a base class with a generic type T that extends that abstract table (AT).

However, only the specific classes generated by build_runner are accepted to work inside DAOs. These classes include a TableInfo mixin wich has a type variable for the generated table and the working type.

To ensure compatibility, I specify that T extends TableInfo<T, dynamic>. Additionally, T must extend my abstract class to include the common columns.

My workaround involves creating another abstract class with the dependencies correctly arranged. However, every time I use build_runner, I must manually add the implements keyword to all generated classes that meet these constraints.

I also asked for help in the Community Discord, and someone (julemand101) suggested creating my own mixin that meets these constraints. However, I can't do this because TableInfo already uses the on keyword and therefore cannot be added in another mixin class. In any case, I would also need to replace it at the generated code.

So what I'm asking here is for both to not generate table for abstract Table classes and if possible to have an underlying type for us to know that a table is generated and extends those base classes.

---

To be more concrete, what I'm doing is something like:

abstract class DAO<T extends ATIdentifier>{
  T get table;

  // Methods

}

Today I have two type constraints for that:

abstract class DAO<T extends AT, ConcreteTable extends TableInfo<T, dynamic>>{
  ConcreteTable get table;

  // Methods

}

Now inside some base methods I already have those fields to work with no matter what. I simply need my DAO to extend this class and to set like late final table = myTable;