-
-
Notifications
You must be signed in to change notification settings - Fork 493
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
Initial event sourcing implementation #3869
Conversation
# Conflicts: # Gemfile # app/controllers/adjustments_controller.rb # app/services/adjustment_create_service.rb # db/schema.rb
@@ -40,6 +40,7 @@ def finalize | |||
ActiveRecord::Base.transaction do | |||
@audit.storage_location.increase_inventory increasing_adjustment | |||
@audit.storage_location.decrease_inventory decreasing_adjustment | |||
AuditEvent.publish(@audit) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried that the @audit.split_differences
routine does weird things, should this event record be above the split_difference, or even higher up than that near the @audit.save
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's in a transaction, so it doesn't really matter. Either all of the records will be created or none of them will.
app/events/adjustment_event.rb
Outdated
event_time: Time.zone.now, | ||
data: EventTypes::InventoryPayload.new( | ||
items: EventTypes::EventLineItem.from_line_items(adjustment.line_items, to: adjustment.storage_location_id) | ||
).as_json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do some of these have .as_json
and others don't?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which ones don't?
@dorner: Your PR/Issue |
26 similar comments
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
@dorner: Your PR/Issue |
This PR shows how we might implement an event sourcing pattern.
The overall approach is as follows:
validate
method into the event processing to indicate if we should apply business logic rules. By default we should only validate when the event is being created. Otherwise we might end up in a bad state when we change business logic rules after the fact.Lots of next steps:
Once that's in place, we can leave it there for a while until we validate the quality of the data.