Can I use "clientDefault" with a non-nullable column?

[mattsimgithub]

Since migrating my moor files to null safe 2.12, I have a number of id columns that are non-nullable, but which are trying to use clientDefault to set a uuid:

class MyClass extends Table {
  TextColumn get id => text().clientDefault(() => _uuid.v4())();

  [...]

  @override
  Set<Column> get primaryKey => {id};
}

When I try to run the app with the new non-nullable columns, I get the following exception (truncated):

Sorry, MyClass(id: null, reportAuthor: MattSim, farmId: null, [...] comments: null) cannot be used for that because: 
id: This column is not nullable and doesn't have a default value. Null fields thus can't be inserted.
#0      VerificationContext.throwIfInvalid (package:drift/src/runtime/data_verification.dart:74:5)

I'd have preferred to have clientDefault trigger before this validation, but it seems to happen later.

In my case, it wouldn't be a big deal to set the id with a uuid manually, prior to the insert, but before I get to doing this, I'd like to make sure I'm not missing a trick. Any thoughts?

[simolus3]

How did you manage to construct a MyClass with id: null under null safety? I would expect the generated data class to have a non-null String id field to reflect the non-nullable column.

Maybe the generated code could be a bit more friendly around clientDefault (we could potentially generate a nullable argument that defaults to the custom default otherwise). But in general, the idea is that you'd use the generated companion classes to represent partial rows. So you could use MyClassCompanion.insert to construct a companion that only requires what's necessary for inserts, all default values will be filled later.

[mattsimgithub]

How did you manage to construct a MyClass with id: null under null safety?

I'm flailing my way through this and, hey, that's where I ended up. 😁

Most of the app is not yet migrated to null safety. Creating the MyClass object in question is not null safe yet. At a guess, this allows behavior that maybe shouldn't be allowed, and won't be allowed once that code is migrated.

I would expect the generated data class to have a non-null String id field to reflect the non-nullable column.

Yes, it does:

class MyClass extends DataClass
    implements Insertable<MyClass> {
  final String id;
  final String reportAuthor;
  [...]
  MyClass(
      {required this.id,
      required this.reportAuthor,
      [...]

But in general, the idea is that you'd use the generated companion classes to represent partial rows. So you could use MyClassCompanion.insert to construct a companion that only requires what's necessary for inserts, all default values will be filled later.

👍

Right now, I think applying a uuid at object creation will be simpler, but I will keep the companion approach in mind in case this turns into many issues like this one.