prooph / event-store

PHP 7.4 EventStore Implementation
http://getprooph.org
BSD 3-Clause "New" or "Revised" License
547 stars 74 forks source link

Best practice CI/CD #432

Closed sseypt closed 1 year ago

sseypt commented 1 year ago

Hello.

The ReadModel currently contains the table structure in the init(). Until now, when adding new fields, the table has to be deleted manually and the projection is then created again.

How do you automate this process?

I have 2 ideas.

1) I keep the init() up to date and use Doctrine Migrations to clear the table when changes are made, so that it is repopulated with the changed insert(array $data).

1b) I don't update the init() and manage the changes directly in Doctrine Migrations. In that case, I can't delete the table, but I have to reset the projection within the migration so that it is refilled.

2) I compare a hash of each table structure at each deploy and store them in a separate table (like migration_versions). If a hash has changed, I delete the table and have it recreated.

Neither seems ideal. With 1. I use migrations in parallel with init() and to call methods to restore the projection. In 2. I build a stripped down version of doctrine migrations.

Neither allows me to keep the projection. For example, when removing a field, I could simply delete it from the table. With (1) I could manage that, but with (2) I don't know why the hash has changed. Also, if I want to be economical with a full reset, another developer with an older state may need to run multiple migrations in succession and I'll need to make sure the table is present and populated after each migration. Which I would normaly not do and have the supervisor processes deal with this once I restart them. That would then have to be covered in the migration as well.

I lack a clever idea or way to repopulate only the changed fields.

I welcome any input.

Cheers, Steve

fritz-gerneth commented 1 year ago

We usually create a new read model for this and let it replay from the start.

If you find yourself needing to update the same read model too often, chances are you have too large read models. Consider them throw-away ware, for a single purpose or query only. They do not need to follow any traditional DB design best practices. We have many read-models that only have like 2-3 columns.

sseypt commented 1 year ago

Thank you for the quick response. I have to admit, my knowledge of prooph and event stores is very rudimentary. My focus here is on CI/CD. Therefore, the question is probably very trivial. So, ideally, projections consist of multiple ReadModels, or is a 1:1 approach also recommended?

fritz-gerneth commented 1 year ago

I would recommend a 1:1 approach (as it is the projection that keeps the replay-state / event-stream positions). That way you can also throw away old read-models/projects rather easily when no longer needed. They also become faster & easier to build 😊