Migration : from clientDefault to withDefault

[ad-angelo]

Hello,

I am trying to switch my table from clientDefault to withDefault. What is the correct way to handle the migration ?

What I have done

1. Switching table definition :

-BoolColumn get isMonthly => boolean().clientDefault(() => false)();
+BoolColumn get isMonthly => boolean().withDefault(const Constant(false))();

-DateTimeColumn get createdAt => dateTime().clientDefault(() => DateTime.now())();
+DateTimeColumn get createdAt => dateTime().withDefault(currentDateAndTime)();

2. Bump the schemaVersion

3. Run dart run drift_dev make-migrations

4. Write the migration :

from2To3: (m, schema) async {
 // Switch clientDefault to withDefault
 await m.alterTable(TableMigration(schema.transactions));
},

Is this OK, can I go into production with this ?

Why am I doing this ?

During development I used clientDefault as mentioned in the doc

clientDefault is recommended over withDefault() for most use cases as it offers more flexibility and does not require a database migration.

Recently, when I added a new column with clientDefault, the make-migrations tool warned me that the default value was missing. So I used withDefault for this new column.
Therefore, it makes no sense to me to have some default values with clientDefault and others with withDefault.

Final thought

The doc mentions the care required for the default value during migration, but I could not find any information on how to handle this properly.

Adding, removing, or changing the default value is considered a schema change that requires special care.

Thanks a lot for your help !!

[dickermoshe]

That looks fine. Run the schema tests to confirm.

the make-migrations tool warned me that the default value was missing.

What was the warning?

[ad-angelo]

Thanks for the quick reply !

If I add this column :

  BoolColumn get foo => boolean().clientDefault(() => false)();

The dart run drift_dev make-migrations return this

INFO: Hint: Your latest migration might benefit from a test with data, as it might need special setup to transform existing data. Drift has detected the following reasons for that: 
INFO:  - Added column "foo" in "categories" without a default.
INFO: For more information on writing these tests, see https://drift.simonbinder.eu/migrations/tests/#verifying-data-integrity

[simolus3]

That warning is not applicable if you go from clientDefault to withDefault, but if you add a new column with a clientDefault only, it's something to consider.

The reason is that alterTable just runs a bunch of SQL statements and can't inspect clientDefault. So when the new column is added, the default would be missing. You could use a column transformer to set a fixed value for rows that already existed before the migration. But since this isn't trivial to get right, drift suggests you specifically test the migration with previous rows.

[ad-angelo]

Yes that is perfectly right. This warning only occurs when I try to add the new column for the first time with clientDefault. Indeed, when I then tried to add new rows, the default value was missing.
I totally understood from the documentation you pointed out that adding a column with clientDefault requires a special statement.

This is why I preferred to use withDefault over clientDefault for this new column, to make the migration easy and straightforward :

from1To2: (m, schema) async {
 await m.addColumn(schema.categories, schema.categories.hide);
},

As I said, to maintain good code consistency, I switched all my row definitions from clientDefault to withDefault.
I just wanted to know if I am doing this correctly and if it will cause any problems :

What I have done

1. Switching table definition :

-BoolColumn get isMonthly => boolean().clientDefault(() => false)();
+BoolColumn get isMonthly => boolean().withDefault(const Constant(false))();

-DateTimeColumn get createdAt => dateTime().clientDefault(() => DateTime.now())();
+DateTimeColumn get createdAt => dateTime().withDefault(currentDateAndTime)();

2. Bump the schemaVersion
3. Run dart run drift_dev make-migrations
4. Write the migration :

from2To3: (m, schema) async {
 // Switch clientDefault to withDefault
 await m.alterTable(TableMigration(schema.transactions));
},

Is this OK, can I go into production with this ?

Ok for you too @simolus3 ?

[simolus3]

Is this OK, can I go into production with this ?

Looks good to me 👍

[dickermoshe]

@simolus3 This discussion seems to be a great reason to separate sqlite schema from datamodel

[ad-angelo]

Hi @dickermoshe !
Could you explain a little more for my curiosity, please?

[ad-angelo]

What about it ?

Adding, removing, or changing the default value is considered a schema change that requires special care.

Am I missing something ? Where in the doc can I find the proper way to handle this with withDefault ?

[simolus3]

Where in the doc can I find the proper way to handle this with withDefault ?

Changes to the value crated by withDefault? You just run a default await m.alterTable(TableMigration(schema.transactions)) to apply the change. New rows would use the new default value, old rows wouldn't be affected.