You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: patterns/trigger-lite/README.md
+13-5Lines changed: 13 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,9 @@ The trigger-lite pattern provides automatic Change Data Capture (CDC) for SQLite
6
6
7
7
The pattern consists of three main components:
8
8
9
-
### 1. Changes Table
9
+
### 1. Changes Tables
10
10
11
-
A central table that tracks all modifications across your application tables:
11
+
A changes table that tracks all modifications across your application tables:
12
12
13
13
```sql
14
14
CREATETABLEchanges (
@@ -19,7 +19,15 @@ CREATE TABLE changes (
19
19
) WITHOUT ROWID;
20
20
```
21
21
22
-
See `setup_changes_table()` in [pattern.py] for the implementation.
22
+
And a table used to track the maximum global sequence number:
23
+
24
+
```sql
25
+
CREATETABLEIF NOT EXISTS changes_gsn (
26
+
max_gsn INTEGERNOT NULL-- Maximum GSN
27
+
)
28
+
```
29
+
30
+
See `setup_changes_tables()` in [pattern.py] for the implementation.
23
31
24
32
### 2. Database Triggers
25
33
@@ -37,7 +45,7 @@ See `setup_triggers()` in [pattern.py] for the implementation.
37
45
38
46
A context manager that atomically:
39
47
40
-
1. Captures the current GSN
48
+
1. Captures the current max GSN
41
49
2. Generates changesets by joining application tables with the changes table
42
50
3. Returns typed operations (`UpsertOp` for inserts/updates, `DeleteOp` for deletes)
43
51
4. Automatically cleans up processed changes
@@ -48,7 +56,7 @@ See `changeset()` in [pattern.py] for the implementation.
48
56
49
57
Periodically a Checkpoint should be created to allow the history of changesets to restart. This ensures that the history doesn't get too long, as well as serving as a backup should something go wrong.
50
58
51
-
Before Checkpointing the database, you must truncate the `changes` table. This effectively resets the change history allowing it to start from scratch.
59
+
Before Checkpointing the database, you must truncate the `changes` table. This effectively resets the change history allowing it to start from scratch. You may choose to reset the max_gsn to 0 in `changes_gsn` table as well, although that is not needed. It is safer to never reset the max_gsn.
52
60
53
61
After running compaction and generating a Checkpoint, the database history is fully reset. The resulting Checkpoint needs to be sent to any replicas in entirely before replicating changes can resume.
0 commit comments