Renaming an old column causes error in the previous migration code used for adding that old column

[cal-g]

I'm trying to rename a column and to do so I use the Migrator.renameColumn and then re-generate the database code.

But in a previous migration step, I had added that same column using Migrator.addColumn and now after the new database code is generated it results in a analyzer error on the GeneratedColumn passed to Migrator.addColumn.

e.g. Suppose in this , I add another migration to rename the dueDate column to just date.

class Todos extends Table {
  // Other columns
  DateTimeColumn get date => dateTime().nullable()(); // renamed in v4
}

@override
int get schemaVersion => 4;

@override
MigrationStrategy get migration {
return MigrationStrategy(
    onCreate: (Migrator m) async {
      await m.createAll();
    },
    onUpgrade: (Migrator m, int from, int to) async {
      if (from < 2) {
        // we added the dueDate property in the change from version 1 to
        // version 2
        await m.addColumn(todos, todos.dueDate);
      }
      if (from < 3) {
        // we added the priority property in the change from version 1 or 2
        // to version 3
        await m.addColumn(todos, todos.priority);
      }
      if (from < 4) {
        await m.renameColumn(todos, 'due_date', todos.date);
      }
    },
  );
}

Doing this, will cause the analyzer error in m.addColumn(todos, todos.dueDate) of version 2.

Is there a way to rename the column without breaking the previous migration code ? Maybe the previous migration code needs some adjustment ?

Thanks

[simolus3]

This is another thing that would be much easier with schema migration helpers, which give you a snapshot of all previous schemas in your apps (so you can do from1To2: (m, schema) async { await m.addColumn(schema.todos, schema.todos.dueDate); } without ever having to change your code).
If you can still migrate to these helpers by running dart run drift_dev schema dump at different git revisions of your app, that may be worth it just to solve these kinds of issues. It also lets you unit test you migrations. We will point out this feature more strongly on the docs soon.

Maybe the previous migration code needs some adjustment ?

The only thing that comes to mind unfortunately is to use customStatement, e.g. await customStatement('ALTER TABLE todos ADD COLUMN due_date;');.

[cal-g]

Thanks, @simolus3! The schema migration helpers look like exactly what I need. Also, I appreciate the customStatement solution.