zilverline/sequent

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:

  1. store this data in a separate table and join when needed
  2. if this data is important for the aggregate it should be in an event of this aggregate