Are you thinking ahead to support NNBD for Dart?
It would be especially magical if the generated DataClass respected calls to .nullable on the ColumnBuilder.
class Things extends Table {
TextColumn get id => text().nullable()();
TextColumn get owner => text()();
...
class Thing extends DataClass implements Insertable<Thing> {
final String? id;
final String owner;
...
There was definitively some discussion in some issue where NNBD and that particular use case was brought up so I am sure this will be in the library once NNBD lands.
See https://github.com/simolus3/moor/issues/606 for some thoughts on NNBD usage/features.
Edit:
Well, the issue doesn't really fit but yea, now it is linked 馃か
Edit 2:
This is actually the comment I was looking for: https://github.com/simolus3/moor/issues/548#issuecomment-624533341
Yes, I definitely want moor to support NNBD eventually. I designed most of the library with eventual null-safety in mind (which for instance, is why we have companions for partial rows), so I hope moor can migrate without changing its public api too much. To still leave some room for minor breaking changes, I'm targeting the next breaking release for the migration.
For moor, a migration to null-safety means more work than just migrating the core package. As you mentioned, the generator will have to be adapted to output NNBD code too. For moor files and analyzed sql queries, type inference around nullability needs to be stabilized as well.
In their roadmap introduced today, the Dart team suggests waiting for a beta version of null-safety before packages start to opt-in.To avoid breaking changes, moor can only start to migrate after its dependencies have migrated. Since it takes a lot of work to maintain a null-safe fork along with the actual package development, I prefer to get the migration done quickly even if it means I have to start a bit later. Moor doesn't have that many dependencies though, and most packages by the Dart team have already been migrated.
Thanks for taking the time to explain the vision for this package, I trust we鈥檙e in good hands then.
Most helpful comment
Yes, I definitely want moor to support NNBD eventually. I designed most of the library with eventual null-safety in mind (which for instance, is why we have companions for partial rows), so I hope moor can migrate without changing its public api too much. To still leave some room for minor breaking changes, I'm targeting the next breaking release for the migration.
For moor, a migration to null-safety means more work than just migrating the core package. As you mentioned, the generator will have to be adapted to output NNBD code too. For moor files and analyzed sql queries, type inference around nullability needs to be stabilized as well.
In their roadmap introduced today, the Dart team suggests waiting for a beta version of null-safety before packages start to opt-in.To avoid breaking changes, moor can only start to migrate after its dependencies have migrated. Since it takes a lot of work to maintain a null-safe fork along with the actual package development, I prefer to get the migration done quickly even if it means I have to start a bit later. Moor doesn't have that many dependencies though, and most packages by the Dart team have already been migrated.