1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
/**
* The changes virtual table is an eponymous virtual table which can be used
* to fetch and apply patches to a db.
*
* To fetch a changeset:
* ```sql
* SELECT * FROM crsql_chages WHERE site_id IS NOT SITE_ID AND version > V
* ```
*
* The site id parameter is used to prevent a site from fetching its own
* changes that were patched into the remote.
*
* The version parameter is used to get changes after a specific version.
* Sites should keep track of the latest version they've received from other
* sites and use that number as a cursor to fetch future changes.
*
* The changes table has the following columns:
* 1. table - the name of the table the patch is from
* 2. pk - the primary key(s) that identify the row to be patched. If the
* table has many columns that comprise the primary key then
* the values are quote concatenated in pk order.
* 3. col_vals - the values to patch. quote concatenated in cid order.
* 4. col_versions - the cids of the changed columns and the versions of those
* columns
* 5. version - the min version of the patch. Used for filtering and for sites
* to update their "last seen" version from other sites
* 6. site_id - the site_id that is responsible for the update. If this is 0
* then the update was made locally.
*
* To apply a changeset:
* ```sql
* INSERT INTO changes (table, pk, col_vals, col_versions, site_id) VALUES
* (...)
* ```
*/
extern sqlite3_module crsql_changesModule;
/**
* Data maintained by the virtual table across
* queries.
*
* Per-query data is kept on crsql_Changes_cursor
*/
typedef struct crsql_Changes_vtab crsql_Changes_vtab;
;
/**
* Cursor used to return patches.
* This is instantiated per-query and updated
* on each row being returned.
*
* Contains a reference to the vtab structure in order
* get a handle on the db which to fetch from
* the underlying crr tables.
*
* Most columns are passed-through from
* `pChangesStmt` and `pRowStmt` which are stepped
* in each call to `changesNext`.
*
* `colVersion` is copied given it is unclear
* what the behavior is of calling `sqlite3_column_x` on
* the same column multiple times with, potentially,
* different types.
*
* `colVersions` is used in the implementation as
* a text column in order to fetch the correct columns
* from the physical row.
*
* Everything allocated here must be constructed in
* changesOpen and released in changesCrsrFinalize
*/
typedef struct crsql_Changes_cursor crsql_Changes_cursor;
;