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: README.md
+17-16Lines changed: 17 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ For scalability details, see [benchmarks](/benchmarks/README.md).
12
12
13
13
## How it works
14
14
15
-
We just need to have a few tables (postgres syntax, schema managed by EventSQL):
15
+
We just need to have a few tables (postgres syntax, schema managed fully by EventSQL):
16
16
17
17
```sql
18
18
CREATETABLEtopic (
@@ -33,17 +33,15 @@ CREATE TABLE consumer (
33
33
PRIMARY KEY (topic, name, partition)
34
34
);
35
35
36
-
CREATETABLEevent (
37
-
topic TEXTNOT NULL,
38
-
id BIGSERIALNOT NULL,
36
+
CREATE TABLE {topic}_event (
37
+
id BIGSERIALPRIMARY KEY,
39
38
partition SMALLINTNOT NULL,
40
39
key TEXT,
41
40
value BYTEANOT NULL,
42
41
buffered_at TIMESTAMPNOT NULL,
43
42
created_at TIMESTAMPNOT NULL DEFAULT NOW(),
44
-
metadata JSON NOT NULL,
45
-
PRIMARY KEY (topic, id)
46
-
) PARTITION BY LIST (topic);
43
+
metadata JSON NOT NULL
44
+
);
47
45
48
46
-- Same schema as event, just not partitioned. --
49
47
-- It is used to handle eventual consistency of auto increment; --
@@ -52,8 +50,8 @@ CREATE TABLE event (
52
50
-- they are then moved to event table in bulk, by a single, serialized writer; --
53
51
-- because there is only one writer, it fixes eventual consistency issue --
54
52
CREATETABLEevent_buffer (
55
-
topic TEXTNOT NULL,
56
53
id BIGSERIALPRIMARY KEY,
54
+
topic TEXTNOT NULL,
57
55
partition SMALLINTNOT NULL,
58
56
key TEXT,
59
57
value BYTEANOT NULL,
@@ -63,12 +61,12 @@ CREATE TABLE event_buffer (
63
61
-- Used to lock single event_buffer to event writer; --
64
62
-- there cannot be more than one record of this table! --
65
63
CREATETABLEevent_buffer_lock (
66
-
created_at TIMESTAMPNOT NULL DEFAULT NOW()
64
+
id TEXTPRIMARY KEY
67
65
);
68
-
INSERT INTO event_buffer_lock VALUES (DEFAULT);
66
+
INSERT INTO event_buffer_lock VALUES ('singleton-lock');
69
67
```
70
68
71
-
To consume messages, we just need to periodically (every one to a few seconds) do:
69
+
To consume events, we just need to periodically (every one to a few seconds) do:
72
70
73
71
```sql
74
72
BEGIN;
@@ -77,8 +75,8 @@ SELECT * FROM consumer
77
75
WHERE topic = :topic AND name = :c_name
78
76
FOR UPDATE SKIP LOCKED;
79
77
80
-
SELECT*FROMevent
81
-
WHEREtopic = :topic AND(:last_event_id IS NULLOR id > :last_event_id)
78
+
SELECT*FROM{topic}_event
79
+
WHERE (:last_event_id IS NULLOR id > :last_event_id)
82
80
ORDER BY id LIMIT :limit;
83
81
84
82
(process events)
@@ -105,8 +103,8 @@ SELECT * FROM consumer
105
103
WHERE topic = :topic AND name = :c_name AND partition =0
106
104
FOR UPDATE SKIP LOCKED;
107
105
108
-
SELECT*FROMevent
109
-
WHEREtopic = :topic ANDpartition =0AND (:last_event_id IS NULLOR id > :last_event_id)
106
+
SELECT*FROM{topic}_event
107
+
WHERE partition =0AND (:last_event_id IS NULLOR id > :last_event_id)
110
108
ORDER BY id LIMIT :limit;
111
109
112
110
(process events)
@@ -142,6 +140,9 @@ ver shardedEventSQL = new EventSQL(dataSources, EventSQLDialect.POSTGRES);
142
140
143
141
Sharded version works in the same vain - it just assumes that topics and consumers are hosted on multiple dbs.
144
142
143
+
Required tables are managed automatically by the library, but if you want to customize their schema a bit, you can provide your own `EventSQLRegistry.TableManager` implementation.
144
+
See `EventSQLRegistry` for details.
145
+
145
146
### Topics and Consumers
146
147
147
148
Having `EventSQL` instance, we can register topics and their consumers:
@@ -248,7 +249,7 @@ var consumers = eventSQL.consumers();
0 commit comments