Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RES 3.0 integration #1561

Draft
wants to merge 59 commits into
base: master
Choose a base branch
from
Draft

RES 3.0 integration #1561

wants to merge 59 commits into from

Conversation

mostlyobvious
Copy link
Member

@mostlyobvious mostlyobvious commented Jan 30, 2023

All breaking 3.0 changes in one place.

Including:

  • no RailsEventStore aliases on RubyEventStore consts
  • no implicit serialization in ActiveRecord with jsonb columns, thus minimal supported Rails version 6.1
  • ArgumentError when passing nil to publish and link
  • dropping rails_event_store_active_record wrapper and depending directly on ruby_event_store-active_record gem in rails_event_store
  • dropping deprecated JSONMapper
  • dropping deprecated NullMapper
  • dropping apply_guessed_method_name_from_event in AggregateRoot
  • dropping global event store configuration in AggregateRoot
  • dropping deprecated EventClassRemapper (upcasting is a preferred alternative)
  • InMemoryRepository detecting mixed usage of expected_version (:any + Integer) by default
  • renaming instrumenter names and arguments for consistency
  • breaking changes in Projection API
  • moving EventClassRemapper to ruby_event_store-transformations gem in case someone relied on it
  • opportunity to redesign AggregateRoot around AggregateRoot OnDSL and DefaultApplyStrategy always go together #982
  • Simplify dispatcher verify method. Anything responding to call will be a valid handler.

Nice to have:

@lukaszreszke
Copy link
Contributor

lukaszreszke commented Feb 6, 2023

moving EventClassRemapper to ruby_event_store-transformations gem in case someone relied on it

done

mostlyobvious and others added 23 commits September 29, 2023 12:56
Projection class is redesigned here. It now only suports read & reduce
based on existing events, without possibility to subscribe for events.

New & redesigned:
* replace `from_all_streams` & `from_stream` with passing read scopes
  to `call` method, it allows to fully use all read specification
  features to define what events should be handled
* instead of providing several streams (and starting points) to be
  processed `call` expects several read scopes
* `when` method replaced with `on` method, with usage consistent with
  `on` handlers (as in `AggregateRoot`), the `on` methods require block
  to process state & event and it must return new projection state
* allows to use simple values as initial state, no need to use hash to
  pass values, `nil` is the initial default state now
* initial state is passed to projection using costructor

Typical usage:

```ruby
account_balance =
  RailsEventStore::Projection
    .new(0.0)
    .on(MoneyDeposited) { |state, event| state += event.data[:amount] }
    .on(MoneyWithdrawn) { |state, event| state -= event.data[:amount] }
    .call(client.read)
```
DefaultApplyStrategy relies on OnDSL. Therefore they always have to go
together.

https: //github.com//issues/982

Co-authored-by: Paweł Pacana <[email protected]>
Co-authored-by: Szymon Fiedler <[email protected]>
Co-authored-by: Szymon Fiedler <[email protected]>
Co-authored-by: Paweł Pacana <[email protected]>
Co-authored-by: Paweł Pacana <[email protected]>
Co-authored-by: Szymon Fiedler <[email protected]>
Co-authored-by: Paweł Pacana <[email protected]>
Co-authored-by: Szymon Fiedler <[email protected]>
All we need is subscriber responding to `call` method.
Therefore, passing class is not allowed anymore. It either has to be
class instance or something that evaluates to class instance.
The dispatcher doesn't indicate that the message will be handled
asynchronously. It indicates that the event will be dispatched
immediately. No matter if it's handled sync or async
Basically same reason as ImmediateAsyncDispatcher -> ImmediateDispatcher
Co-authored-by: Paweł Pacana <[email protected]>
Co-authored-by: Szymon Fiedler <[email protected]>
Co-authored-by: Paweł Pacana <[email protected]>
Not a practical example. Hard to imagine real life use case for passing
anonymous class.

Co-authored-by: Paweł Pacana <[email protected]>
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?
Rely on the new default instead of explicitly setting it
The reason is the "Why we’re deprecating the automatic conversion"
section in the article below

https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/
mostlyobvious and others added 6 commits September 29, 2023 13:31
Co-authored-by: Szymon Fiedler <[email protected]>
Co-authored-by: Szymon Fiedler <[email protected]>
Mutant had a doubt that Transformation::ProtobufNestedStructMetadata is
passed. When not passed, tests would fail on deserialize part not being
able to merge timestamp and valid_at to already serialized binary string.

No test checked how messages is serialized to prove that transformation
is needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants