A typical source for Projections is the change stored with @apidoc[DurableStateBehavior$] in @extref:Apache Pekko Persistence. Durable state changes can be @extref:tagged and then consumed with the @extref:changes query.
Apache Pekko Projections has integration with changes, which is described here.
@@@ note { title=Alternative } When using the R2DBC plugin an alternative to using a Projection is to @extref:store the query representation directly from the write side. @@@
To use the Durable State module of Apache Pekko Projections, add the following dependency in your project:
@@dependency [sbt,Maven,Gradle] { group=org.apache.pekko artifact=pekko-projection-durable-state_$scala.binary.version$ version=$project.version$ }
Apache Pekko Projections requires Pekko $pekko.version$ or later, see @ref:Pekko version.
@@project-info{ projectId=“durable-state” }
The table below shows the pekko-projection-durable-state direct dependencies.The second tab shows all libraries it depends on transitively.
@@dependencies{ projectId=“durable-state” }
A @apidoc[SourceProvider] defines the source of the envelopes that the Projection will process. A SourceProvider for the changes query can be defined with the @apidoc[DurableStateStoreProvider$] like this:
Scala : @@snip DurableStateStoreDocExample.scala { #changesByTagSourceProvider }
Java : @@snip DurableStateStoreDocExample.java { #changesByTagSourceProvider }
This example is using the DurableStateStore JDBC plugin for Apache Pekko Persistence. You will use the same plugin that you configured for the write side. The one that is used by the DurableStateBehavior.
This source is consuming all the changes from the Account DurableStateBehavior that are tagged with "bank-accounts-1". In a production application, you would need to start as many instances as the number of different tags you used. That way you consume the changes from all entities.
The @scala[DurableStateChange[AccountEntity.Account]]@java[DurableStateChange<AccountEntity.Account>] is what the Projection handler will process. It contains the State and additional meta data, such as the offset that will be stored by the Projection. See @apidoc[pekko.persistence.query.DurableStateChange] for full details of what it contains.
A @apidoc[SourceProvider] defines the source of the envelopes that the Projection will process. A SourceProvider for the changesBySlices query can be defined with the @apidoc[DurableStateStoreProvider$] like this:
Scala : @@snip DurableStateStoreDocExample.scala { #changesBySlicesSourceProvider }
Java : @@snip DurableStateStoreDocExample.java { #changesBySlicesSourceProvider }
This example is using the @extref:R2DBC plugin for Apache Pekko Persistence. You will use the same plugin that you configured for the write side. The one that is used by the DurableStateBehavior.
This source is consuming all the changes from the Account DurableStateBehavior for the given slice range. In a production application, you would need to start as many instances as the number of slice ranges. That way you consume the changes from all entities.
The @scala[DurableStateChange[AccountEntity.Account]]@java[DurableStateChange<AccountEntity.Account>] is what the Projection handler will process. It contains the State and additional meta data, such as the offset that will be stored by the Projection. See @apidoc[pekko.persistence.query.DurableStateChange] for full details of what it contains.