Moor: Support for non-nullable (NNBD) Dart

Created on 1 Oct 2020  路  4Comments  路  Source: simolus3/moor

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;
...
enhancement

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.

All 4 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kira1752 picture kira1752  路  3Comments

tony123S picture tony123S  路  4Comments

johrpan picture johrpan  路  4Comments

KKRoko picture KKRoko  路  3Comments

felixjunghans picture felixjunghans  路  4Comments