Skip to content

Commit

Permalink
Using projection with event type defined by event's class
Browse files Browse the repository at this point in the history
During an attempt to introduce event_type_resolver into projection I
wrote following test. The idea is that you can use two different
versions of event with class level method defining the event type.

In that case, and in usage presented as in test, the event_type_resolver
doesn't bring any value to the projection class. So for now I removed
it.

Perhaps it does make more sense if we're thinking of other way
of using projections?
  • Loading branch information
lukaszreszke committed Feb 13, 2023
1 parent 764512f commit 5cd0154
Showing 1 changed file with 28 additions and 0 deletions.
28 changes: 28 additions & 0 deletions ruby_event_store/spec/projection_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -228,5 +228,33 @@ module RubyEventStore

expect(state).to eq(initial_state)
end

specify "events with event type defined as class method" do
class Snowflake < Event
def self.event_type
"snowflake"
end
end

class SnowflakeV2 < Event
def self.event_type
"snowflake"
end
end

event_store.append(Snowflake.new(data: { arms: 13 }), stream_name: "snowflake$1")
event_store.append(SnowflakeV2.new(data: { arms: 11 }), stream_name: "snowflake$1")

state =
Projection
.init({ snowflake: 0 })
.on(Snowflake, SnowflakeV2) do |state, event|
state[event.class.event_type.to_sym] += event.data.fetch(:arms)

This comment has been minimized.

Copy link
@mostlyobvious

mostlyobvious Feb 13, 2023

Member
  • event instance responds to event_type, no need to peek into class (coupling to test-specific implementation)
  • snowflakes are missing event_type method that presents their true type, that's why you had to "fix" it in the Projection handlers
state
end
.call(event_store.read.stream("snowflake$1"))

expect(state).to eq({ snowflake: 24 })
end
end
end

0 comments on commit 5cd0154

Please sign in to comment.