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

Support ActiveJob adapters with pre-deserialized events and NULL serializer #1335

Closed

Conversation

milgner
Copy link

@milgner milgner commented May 24, 2022

Depending on the configuration of the ActiveJob backend and the serializer used - i.e. the NULL serializer -, it is possible that
the argument to perform is already a full Event record. In that scenario, it can be used as-is without prior processing.

Closes #1334, even if the approach is different from how I understood the problem at first glance. But when taking a closer look at Record, DeserializedRecord and the transformation pipeline I understood better the way things are related and decided on a more straightforward solution and just detecting that specific situation.

Depending on the configuration of the ActiveJob backend and the
serializer used - i.e. the `NULL` serializer -, it is possible that
the argument to `perform` is already a full `Event` record. In that
scenario, it can be used as-is without prior processing.
def self.with_defaults
with
end
class << self
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this was necessary change. Changing to class << self over self. made it harder to notice what really changed. A separate commit with only this change would be helpful in the future.


# @return [Event] an event as deserialized from the payload
def event_from_payload(payload, event_store, serializer)
return payload if payload.kind_of?(RailsEventStore::Event)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't require Event objects in RES to be of this kind. It's likely they are but we accept anything that has the same interface as RES::Event.

@milgner milgner closed this Jan 12, 2023
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.

Decouple serialisation-related logic from AsyncHandler
2 participants