Question: How can i easily add additional columns to the events and streams table?

[butsjoh]

Hi,

Maybe an obvious question to answer but would one add an additional column to the event_store_events and event_store_events_in_streams tables?

We are currently using ruby event store with rom and i am aware of custom mapper and serialise logic (https://railseventstore.org/docs/v1/mapping_serialization/) but i cannot accomplish my goal with that. We have a multitenant app and i want to be able to separate events per tenant using an additional column (tenant_id). I guess i would need to write my own repository implementation todo that (like described here: https://railseventstore.org/docs/v1/repository/)? Or is there something i am missing and could use todo this easily without monkeypatching the rom repository.

[mostlyobvious]

If you need to support your own table structure (i.e. adding additional columns and behaviour around that) going with custom repository is the best.

There is a set of shared examples we run against repositories (active_record, in-memory, rom): https://github.com/RailsEventStore/rails_event_store/blob/master/ruby_event_store/lib/ruby_event_store/spec/event_repository_lint.rb. Those are distributed with ruby_event_store gem:

require 'ruby_event_store/spec/event_repository_lint'

RSpec.describe MyRepository do
  include_examples :event_repository
end

[mostlyobvious]

We have a multitenant app and i want to be able to separate events per tenant using an additional column (tenant_id)

Maybe a viable alternative could be to have separate event tables per tenant?
https://blog.arkency.com/rails-multiple-databases-support-in-rails-event-store/

[mostlyobvious]

We are currently using ruby event store with rom

I'd love to know which ruby event store version are you on!

[mostlyobvious]

btw. we're looking for ROM repository contributor — #834

[butsjoh]

Hi, i will discuss this internally here about becoming a ROM repository contributor related to RES. Our use case is without using rails at all so we cannot use anything rails or active record specific. So i guess making a custom repository is what we will need todo eventually. I will need to look into the event store implementation a bit deeper to see what needs to be changed and how it can be maintained.

[butsjoh]

We are currently using ruby event store with rom

I'd love to know which ruby event store version are you on!

We are on 1.1.1

[leifg]

It's been a while since this question.

We are on the current RES version (2.5.1). Is a custom repository still the best way to amend the events and streams table?

[mostlyobvious]

Is a custom repository still the best way to amend the events and streams table?

It is probably the best way if you intend to drastically change events and steams table. As long as the repository API is preserved you can have any underlying structure and code in custom repository that supports this API.

Somewhere in middle there's an option to pass your own ActiveRecord model classes to repository instance. Perhaps in your usecase that will be enough:
https://github.com/RailsEventStore/rails_event_store/blob/master/rails_event_store_active_record/lib/rails_event_store_active_record/event_repository.rb#L9-L12
https://github.com/RailsEventStore/rails_event_store/blob/master/rails_event_store_active_record/spec/event_repository_spec.rb#L129-L154
You pass model_factory, which responds to #call (i.e. lambda) and returns an array of two ActiveRecord classes. This is useful when you've named your tables differently. Or you need multiple databases.

When you only have additional columns in the tables, that are not used by RES, you probably don't have to do anything.

I'm curious what's your usecase!

[leifg]

When you only have additional columns in the tables, that are not used by RES, you probably don't have to do anything.

This is (kinda) what I'm trying to do. I just want to add an additional column (an aggregate id) to every event. Because the whole pipeline maps everything to RubyEventStore::Record and RubyEventStore::SerializedRecord new fields are however not passed all the way through.

I went pretty far deep down the rabbit hole so it seems the only way to achieve this is to write a completely new repository and I'm starting to think it would be better to just change the stream name to something like by_aggregate_id$<id>.