CODEWITHSUNDEEP
persistencecqrslagom
Simiil
Simiil

Reputation: 2311

Lagom persistent read side and model evolution

To learn lagom i created a simple application with some simple persistent entities and a persistent read side (as per the official documentation, using cassandra)

The official doc contains a section about model evolution, describing how to change the model. However, there is no mention of evolution when it comes to the read side.

Assuming i have an entity called Item, with an ID and a name, and the read side creates a table like CREATE TABLE IF NOT EXISTS items (id TEXT, name TEXT, PRIMARY KEY (id))

I now want to change the item to include a description. This is trivial for the persistent entity, but the read side has to be changed as well.

I can see several approaches to (maybe) achieve that:

  1. use a model evolution tool like liquibase or play evolutions to change the read side tables.
  2. somehow include update table statements in createTables that migrate the model
  3. create additional tables containing the additional information, and keep the old tables without modifications

Which approach would be the most fitting? Is there something better?

Upvotes: 0

Views: 506

Answers (2)

user1569711
user1569711

Reputation: 43

Creating a new table and dropping the old table is an option too IMHO. It is simple as modifying your "create table" command ("create table mytable_v2 ..." and "drop table mytable...") and changing the offset name and modifying your event handlers.

override def buildHandler( ): ReadSideProcessor.ReadSideHandler[MyEvent] = {
      readSide.builder[MyEvent]("myOffset") // change it to "myOffset_v2"
      ...
}

This results in all events to be replayed and your read side table to be reconstructed from the scratch. This may not be an option if the current table is really huge as the recostruction may last very long time.

Regarding what @erip says I see perfectly normal adding a new column to your read side table. Suppose there are lots of records in this table with list of all entities and you want to retrieve a list of entities based on some criteria so you need some columns to be included in the where clause. Retrieving list of all entities and asking each of them if it complies with the criteria is not an option at all - it could be very unefficient as it needs more time, memory and network usage.

Upvotes: 2

erip
erip

Reputation: 16945

The point of a read-side is to materialize views from entity state changes from your service's event stream in your service. In this respect, you as the service controller can decide what is important for your subscribers to know about. This is handled by creating read-sides with an anti-corruption layer (or ACL).

Typically your subscribers will subscribe to API events which should experience no evolution. Your internal events (or impl events) will likely need to evolve; because of this, there should be a transformation from the impl to the API.

This is why it's very important to consider your domain very carefully before design: you really need to nail down what subscribers will need to know about. In the case of a description, it strikes me as unlikely that subscribers will need (or want!) to know about that.

Upvotes: 0

Related Questions