Where's the event payload stored?

Imported from Google Groups
1

I’ve just switched from InMemoryEventStorageEngine to JpaEventStorageEngine. Thanks to some very helpful input from Allard, everything is now working great!

However, for no good reason, other than curiosity, I have gone looking for my serialized events (the payloads) and I can’t find them in the database.

The database schema defines the following 4 tables:

  1. association_value_entry
  2. domain_event_entry
  3. saga_entry
  4. snapshot_event_entry
    In my current implementation I just have a few simple aggregates, no sagas and I haven’t pushed enough events to get a snapshot. So, the only table with any data is domain_event_entry, which is defined as follows:

`

CREATE TABLE domain_event_entry
(
global_index bigint NOT NULL,
event_identifier character varying(255) NOT NULL,
meta_data oid,
payload oid NOT NULL,
payload_revision character varying(255),
payload_type character varying(255) NOT NULL,
time_stamp character varying(255) NOT NULL,
aggregate_identifier character varying(255) NOT NULL,
sequence_number bigint NOT NULL,
type character varying(255),
CONSTRAINT domain_event_entry_pkey PRIMARY KEY (global_index),
CONSTRAINT uk8s1f994p4la2ipb13me2xqm1w UNIQUE (aggregate_identifier, sequence_number),
CONSTRAINT uk_fwe6lsa8bfo6hyas6ud3m8c7x UNIQUE (event_identifier)
)
WITH (
OIDS=FALSE
);

`

Both the meta_data and payload columns are simply a number (an oid), so where’s the actual data?

Thanks!

Troy

2

Hi Troy,

welcome in the world of Postgres. It stores binary data in a separate location, referencing it by ID. It’s a type of “optimization” that doesn’t really optimize anything for the use case of an event store. You can tell Postgres to store data in-line, using TOAST. Not entirely sure how that needs to be configured. It’s a Postgres-specific thing.

Cheers,

Allard

3

Hi Troy, Allard,

The project I’m currently working on uses Postgres to store it’s events and we overcome that ‘optimization’ by enforcing those columns to be of type BYTEA instead of OID.

This required us to introduce a orm.xml which overrides the @Lob annotation (this annotation makes it that Postgres sets it to an OID type) present on the, for example, payload and metadata fields in the Axon entities. This orm.xml is added as a ‘Mapping Resource’ to the EntityManagerFactory.
Additionally, we had to create our own PostgresDialect, in which we had to overwrite the remapSqlTypeDescryptor() function to return a BYTEA type if the type found was BLOB.

Hope this helps you out!

Cheers,

Steven

4

Wow, thanks for the info! I think we will probably be moving to AxonIQ before we go to production, so I think I will just let this go for now.

Cheers,

Troy