Closed
Description
After the move to RBR for messaging, and discussions with @derekperkins, we're simplifying the messaging API. On the upside, this will support all insert constructs. On the downside, the application has more responsibilities on correctness and features. What is changing:
- time_created and time_scheduled are removed from the list of mandatory columns. They will neither be checked nor be populated. If necessary, the application can add these columns and keep them populated.
- The primary key that used to be (time_scheduled,id) is now just id.
- The unique key on id is not required any more, since the PK covers that.
- time_next remains a nullable column, but it's recommended to default it to 0. Setting it to 0 (or any value < now) will schedule the message for immediate delivery. Previously a 0-value was treated as an acked message. This is not the case any more. This means that one could insert a row without specifying a time_next. The code checks for time_acked to contain a non-null (and non-zero) value to determine that a message was acked.
- The default value for epoch can also be 0, but the code treats null values as 0 also.
- Purging is by time_acked. Consequently, a new index is needed on time_acked.
Here's an idiomatic message table definition:
var createMessage = `create table vitess_message(
id bigint,
time_next bigint default 0,
epoch bigint,
time_acked bigint,
message varchar(128),
primary key(id),
index next_idx(time_next, epoch),
index ack_idx(time_acked))
comment 'vitess_message,vt_ack_wait=30,vt_purge_after=120,vt_batch_size=1,vt_cache_size=1000,vt_poller_interval=30'
Here's an idiomatic insert:
insert into vitess_message(id, message) values(1, 'hello world')