In what cases do I have to write a migrator?

[madsane29]

For example do I need to do anything if I set maxLength before on a textColumn and now I try to increase/decrease the value of it?

TextColumn? get myStringColumn=> text().withLength(min: 0, max: 100).nullable()();

to

TextColumn? get myStringColumn=> text().withLength(min: 0, max: 3000).nullable()();

What about if I modify the nullable column to non-nullable? What about non-nullable to nullable?

I wonder if there is a very long list that contains these information and more that I might run into sooner or later.

Thanks in advance.

[simolus3]

I general, I suggest always doing a migration when changing a table. withLength is one of the few exceptions since it's validated in Dart and doesn't get written to the database schema (as explained in its documentation).

What about non-nullable to nullable?

You need a migration here for sure! Non-nullable columns get a special NOT NULL flag in their SQL which is checked by the database. So if you change the column to be nullable without a migration, adding a null value would throw an exception.

What about if I modify the nullable column to non-nullable?

You could technically pull this off without a migration, but I very strongly suggest adding one. This has two reasons:

1. You want to get errors if you somehow manage to insert a null value into a non-nullable column to avoid the database schema becoming invalid.
2. When changing a column to be non-nullable, you'll want to make sure that no NULL values are remaining in that column (or add a default if needed).

Migrations changing columns are usually pretty easy to write by using this API.

Another neat thing that drift can do for you is check whether your database schema matches what it expects. You can just check this when opening your database. Whenever you change your tables and forget to write a migration, drift is then going to tell you what differences it expected in the schema. That way, you catch errors early if there are issues with the schema.