Context
We are using drift_dev in a large Dart workspace where the drift build is now the dominant part of our local codegen loop. With a hot build cache, non-drift phases complete in under a second, while a dirty drift input can still spend minutes in the analyzer pass.
The expensive case for us is small schema churn: adding or changing one column in one table still causes a broad analyzer/codegen pass over the drift surface. We can reduce the blast radius with package boundaries, generate_for, modular generation, and has_separate_analyzer, but the remaining behavior still appears package-wide rather than per table / per input element.
Question
Would a per-table or otherwise element-incremental drift_dev builder mode be in scope for drift?
The shape I have in mind is similar to Gradle's isolating annotation processor model: a builder declares, or can internally track, that a generated output depends only on one table or a bounded input set, so build invalidation can avoid regenerating / re-analyzing unrelated tables when a single table changes.
Why this matters
For larger databases, the current workaround is architectural: split the drift surface into smaller packages or modules so the whole-program analyzer pass has less to walk. That helps, but it pushes build-system constraints into application structure.
An element-incremental mode would let large projects keep normal drift organization while keeping the local edit-codegen loop proportional to the table or drift file that changed.
Not a blocker
This is an upstream tracking / design question, not a request blocking our migration. If this is already covered by modular generation internals or a planned builder change, a pointer would be enough.
Context
We are using
drift_devin a large Dart workspace where the drift build is now the dominant part of our local codegen loop. With a hot build cache, non-drift phases complete in under a second, while a dirty drift input can still spend minutes in the analyzer pass.The expensive case for us is small schema churn: adding or changing one column in one table still causes a broad analyzer/codegen pass over the drift surface. We can reduce the blast radius with package boundaries,
generate_for, modular generation, andhas_separate_analyzer, but the remaining behavior still appears package-wide rather than per table / per input element.Question
Would a per-table or otherwise element-incremental
drift_devbuilder mode be in scope for drift?The shape I have in mind is similar to Gradle's isolating annotation processor model: a builder declares, or can internally track, that a generated output depends only on one table or a bounded input set, so build invalidation can avoid regenerating / re-analyzing unrelated tables when a single table changes.
Why this matters
For larger databases, the current workaround is architectural: split the drift surface into smaller packages or modules so the whole-program analyzer pass has less to walk. That helps, but it pushes build-system constraints into application structure.
An element-incremental mode would let large projects keep normal drift organization while keeping the local edit-codegen loop proportional to the table or drift file that changed.
Not a blocker
This is an upstream tracking / design question, not a request blocking our migration. If this is already covered by modular generation internals or a planned builder change, a pointer would be enough.