From c3d2065d9672b8b065ae1abc40860be16d5e2264 Mon Sep 17 00:00:00 2001
From: Simon Binder <oss@simonbinder.eu>
Date: Sat, 9 Sep 2023 15:32:56 +0200
Subject: [PATCH] Fix example snippet

---
 docs/lib/snippets/migrations/migrations.dart  | 23 +++++++++----------
 .../docs/Advanced Features/migrations.md      | 10 ++++----
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/docs/lib/snippets/migrations/migrations.dart b/docs/lib/snippets/migrations/migrations.dart
index 9af24251..062e7b74 100644
--- a/docs/lib/snippets/migrations/migrations.dart
+++ b/docs/lib/snippets/migrations/migrations.dart
@@ -168,7 +168,7 @@ extension StepByStep2 on GeneratedDatabase {
   }
 }
 
-extension StepByStep3 on GeneratedDatabase {
+extension StepByStep3 on Example {
   MigrationStrategy get migration {
     return MigrationStrategy(
       onCreate: (Migrator m) async {
@@ -180,26 +180,25 @@ extension StepByStep3 on GeneratedDatabase {
         // (https://drift.simonbinder.eu/docs/advanced-features/migrations/#tips)
         await customStatement('PRAGMA foreign_keys = OFF');
 
+        // Manually running migrations up to schema version 2, after which we've
+        // enabled step-by-step migrations.
         if (from < 2) {
           // we added the dueDate property in the change from version 1 to
-          // version 2
-          await m.addColumn(schema.todos, schema.todos.dueDate);
-        }
-
-        if (from < 3) {
-          // we added the priority property in the change from version 1 or 2
-          // to version 3
-          await m.addColumn(schema.todos, schema.todos.priority);
+          // version 2 - before switching to step-by-step migrations.
+          await m.addColumn(todos, todos.dueDate);
         }
 
         // At this point, we should be migrated to schema 3. For future schema
         // changes, we will "start" at schema 3.
         await m.runMigrationSteps(
-          from: math.max(3, from),
+          from: math.max(2, from),
           to: to,
+          // ignore: missing_required_argument
           steps: migrationSteps(
-            from3To4: (m, schema) async {
-              // Perform schema migrations for schema 4
+            from2To3: (m, schema) async {
+              // we added the priority property in the change from version 1 or
+              // 2 to version 3
+              await m.addColumn(schema.todos, schema.todos.priority);
             },
           ),
         );
diff --git a/docs/pages/docs/Advanced Features/migrations.md b/docs/pages/docs/Advanced Features/migrations.md
index 529b1dda..07bc0767 100644
--- a/docs/pages/docs/Advanced Features/migrations.md	
+++ b/docs/pages/docs/Advanced Features/migrations.md	
@@ -198,19 +198,19 @@ in debug modes.
 
 #### Moving to step-by-step migrations
 
-If you've been using drift before `stepByStep` was added to the library, or if you've never exported a schema, 
-you can move to step-by-step migrations by pinning the `from` value in `Migrator.runMigrationSteps` to a known 
+If you've been using drift before `stepByStep` was added to the library, or if you've never exported a schema,
+you can move to step-by-step migrations by pinning the `from` value in `Migrator.runMigrationSteps` to a known
 starting point.
 
-This allows you to perform all prior migration work to get the database to the "starting" point for 
+This allows you to perform all prior migration work to get the database to the "starting" point for
 `stepByStep` migrations, and then use `stepByStep` migrations beyond that schema version.
 
 {% include "blocks/snippet" snippets = snippets name = 'stepbystep3' %}
 
-Here, we give a "floor" to the `from` value of `3`, since we've performed all other migration work to get to 
+Here, we give a "floor" to the `from` value of `2`, since we've performed all other migration work to get to
 this point. From now on, you can generate step-by-step migrations for each schema change.
 
-If you did not do this, a user migrating from schema 1 directly to schema 4 would not properly walk migrations
+If you did not do this, a user migrating from schema 1 directly to schema 3 would not properly walk migrations
 and apply all migration changes required.
 
 ### Writing tests