Questions on the serialized event column definition for MySQL

[martinbeentjes]

I am investigating how we can implement Spring Modulith Events in our codebase as an improvement over several database queue tables we use. I see that spring-modulith-events-jdbc is able to a create the EVENT_PUBLICATION table with the following definition:

CREATE TABLE IF NOT EXISTS EVENT_PUBLICATION
(
  ID               VARCHAR(36) NOT NULL,
  LISTENER_ID      VARCHAR(512) NOT NULL,
  EVENT_TYPE       VARCHAR(512) NOT NULL,
  SERIALIZED_EVENT VARCHAR(4000) NOT NULL,
  PUBLICATION_DATE TIMESTAMP(6) NOT NULL,
  COMPLETION_DATE  TIMESTAMP(6) DEFAULT NULL NULL,
  PRIMARY KEY (ID),
  INDEX EVENT_PUBLICATION_BY_COMPLETION_DATE_IDX (COMPLETION_DATE)
);

A question arises on the length of the SERIALIZED_EVENT column. Why is the choice made for a specific length of 4000 characters here?

I can imagine that the average event being passed through is something like:

package org.foobar.petshop.order;

import org.springframework.context.ApplicationEvent;

import java.util.UUID;

record OrderId(Long id) {
};

enum OrderStatus {
    NEW, PROCESSING, PROCESSED, CANCELLED
}

public class OrderUpdatedEvent extends ApplicationEvent {
    private final UUID userId;
    private final OrderId orderId;
    private final OrderStatus orderStatus;

    public OrderUpdatedEvent(Object source, UUID userId, OrderId orderId, OrderStatus orderStatus) {
        super(source);
        this.userId = userId;
        this.orderId = orderId;
        this.orderStatus = orderStatus;
    }
}  

The event is serialized as JSON using Jackson. If I would start extending the event, and put data into it that I can use later, I do see the chance of it getting larger than 4000 characters. I don't expect to run into issues with this soon, but you never know.

So, why is the default when I use JDBC as my persistence for the events set to 4000?

[odrotbohm]

A question arises on the length of the SERIALIZED_EVENT column. Why is the choice made for a specific length of 4000 characters here?

There's no particular reason, except that pretty simple events usually fit into 4k columns. We do not expect folks to use the provided setup scripts for anything but local development. Schemas for other databases such as Postgres even use other column types (TEXT) that do not impose column length limitations. For production usage, we recommend using a database migration tool such as Liquibase or Flyway.