Can we use Sequent.aggregate_repository.load_aggregate inside of projectors to get those data that is missed in event and located in another aggregate
Closed this issue · 1 comments
Following this #383
I have 1 assumption, that this issue may be because of using Sequent.aggregate_repository.load_aggregate
inside of projectors.
For example:
class SomeProjector < Sequent::Projector
manages_tables SomeRecord
on SomethingHappened do |event|
aggregate = Sequent.aggregate_repository.load_aggregate(event.another_aggregate_id, AnotherAggregate)
create_record(SomeRecord, {
aggregate_id: event.aggregate_id,
another_aggregate_id: event.another_aggregate_id,
some_fields_from_another_aggregate: another_aggregate.some_fields
...
)
end
end
And then SomethingHappened
is event triggered by SomeAggregate
. But since I want to include some data, located in another aggregate, I need to call aggregate = Sequent.aggregate_repository.load_aggregate(event.another_aggregate_id, AnotherAggregate)
and use aggregate.some_fields
to get this missed data.
As far as I understood calling Sequent.aggregate_repository.load_aggregate(event.another_aggregate_id, AnotherAggregate)
will return the state of AnotherAggregate
not at the moment when this event happened, but at the moment when we run the migration. Am I correct?
As far as I understood calling Sequent.aggregate_repository.load_aggregate(event.another_aggregate_id, AnotherAggregate) will return the state of AnotherAggregate not at the moment when this event happened, but at the moment when we run the migration. Am I correct?
Yes that is correct. You can use another method for this : Sequent.aggregate_repository.load_aggregate_for_snapshotting(aggregate_id, AntoherAggregate, event.created_at)
as that will return the state of the aggregate on the moment the event happened.
See https://www.sequent.io/docs/concepts/aggregate-repository.html#loading-aggregateroots.
This will slow down the replaying of a projector considerably though, depending on your use case you could also consider:
- store this data in a separate table and join when needed
- if this data is important for the aggregate it should be in an event of this aggregate