sepaarte folder for durable-state docs as per PR review feedback

akka-docs/src/main/paradox/durable-state/persistence-query.md

@@ -16,12 +16,12 @@ To use Persistence Query, you must add the following dependency in your project:
   version=AkkaVersion
 }
 
-This will also add dependency on the @ref[Akka Persistence](persistence.md) module.
+This will also add dependency on the @ref[Akka Persistence](../persistence.md) module.
 
 ## Introduction
 
-Akka persistence query provides a query interface to @ref:[Durable State Behaviors](typed/persistence-durable-state.md).
-These queries are based on asynchronous streams. These streams are similar to the ones offered in the @ref:[Event Sourcing](persistence-query.md)
+Akka persistence query provides a query interface to @ref:[Durable State Behaviors](../typed/durable-state/persistence.md).
+These queries are based on asynchronous streams. These streams are similar to the ones offered in the @ref:[Event Sourcing](../persistence-query.md)
 based implementation. Various state store plugins can implement these interfaces to expose their query capabilities.
 
 One of the rationales behind having a separate query module for Akka Persistence is for implementing the so-called 

akka-docs/src/main/paradox/persistence-query.md

@@ -30,8 +30,8 @@ side of an application, however it can help to migrate data from the write side
 simple scenarios Persistence Query may be powerful enough to fulfill the query needs of your app, however we highly
 recommend (in the spirit of CQRS) of splitting up the write/read sides into separate datastores as the need arises.
 
-For a similar implementation of query interface to @ref:[Durable State Behaviors](typed/persistence-durable-state.md)
-please refer to @ref:[Persistence Query using Durable State](persistence-query-durable-state.md).
+For a similar implementation of query interface to @ref:[Durable State Behaviors](typed/durable-state/persistence.md)
+please refer to @ref:[Persistence Query using Durable State](durable-state/persistence-query.md).
 
 The @extref[Microservices with Akka tutorial](platform-guide:microservices-tutorial/) explains how to
 implement an Event Sourced CQRS application with Akka Persistence and Akka Projections.

akka-docs/src/main/paradox/typed/cqrs-durable-state.md

@@ -1,6 +0,0 @@
-# CQRS
-
-@ref:[DurableStateBehavior](persistence-durable-state.md)s along with [Akka Projections](https://doc.akka.io/docs/akka-projection/current/)
-can be used to implement Command Query Responsibility Segregation (CQRS). For implementing CQRS using @ref:[EventSourcedBehavior](persistence.md), please take a look at the corresponding @ref:[CQRS](cqrs.md) documentation.
-
- 

akka-docs/src/main/paradox/typed/cqrs.md

@@ -2,5 +2,5 @@
 
 @ref:[EventSourcedBehavior](persistence.md)s along with [Akka Projections](https://doc.akka.io/docs/akka-projection/current/)
 can be used to implement Command Query Responsibility Segregation (CQRS). The @extref[Microservices with Akka tutorial](platform-guide:microservices-tutorial/)
-explains how to use Event Sourcing and Projections together. For implementing CQRS using @ref:[DurableStateBehavior](persistence-durable-state.md), please take a look at the corresponding @ref:[CQRS](cqrs-durable-state.md) documentation.
+explains how to use Event Sourcing and Projections together. For implementing CQRS using @ref:[DurableStateBehavior](durable-state/persistence.md), please take a look at the corresponding @ref:[CQRS](durable-state/cqrs.md) documentation.
  

akka-docs/src/main/paradox/typed/durable-state/cqrs.md

@@ -0,0 +1,6 @@
+# CQRS
+
+@ref:[DurableStateBehavior](persistence.md)s along with [Akka Projections](https://doc.akka.io/docs/akka-projection/current/)
+can be used to implement Command Query Responsibility Segregation (CQRS). For implementing CQRS using @ref:[EventSourcedBehavior](../persistence.md), please take a look at the corresponding @ref:[CQRS](../cqrs.md) documentation.
+
+ 

akka-docs/src/main/paradox/typed/durable-state/persistence.md

@@ -20,7 +20,7 @@ To use Akka Persistence, add the module to your project:
   scope2=test
 }
 
-You also have to select durable state store plugin, see @ref:[Persistence Plugins](../persistence-plugins.md).
+You also have to select durable state store plugin, see @ref:[Persistence Plugins](../../persistence-plugins.md).
 
 @@@ note
 
@@ -41,7 +41,7 @@ This model of Akka Persistence enables a stateful actor / entity to store the fu
 
 The current state is always stored in the database. Since only the latest state is stored, we don't have access to any of the history of changes, unlike event sourced storage. Akka Persistence would read that state and store it in memory. After processing of the command is finished, the new state will be stored in the database. The processing of the next command will not start until the state has been successfully stored in the database.
 
-Akka Persistence also supports @ref:[Event Sourcing](persistence.md) based implementation, where only the _events_ that are persisted by the actor are stored, but not the actual state of the actor. By storing all events, using this model, 
+Akka Persistence also supports @ref:[Event Sourcing](../persistence.md) based implementation, where only the _events_ that are persisted by the actor are stored, but not the actual state of the actor. By storing all events, using this model, 
 a stateful actor can be recovered by replaying the stored events to the actor, which allows it to rebuild its state.
 
 The database specific implementations can be added to existing Akka Persistence plugin implementations, starting with the JDBC plugin. The plugin would serialize the state and store as a blob with the persistenceId as the primary key. Since each entity
@@ -74,10 +74,10 @@ Next we'll discuss each of these in detail.
 The @apidoc[akka.persistence.typed.PersistenceId] is the stable unique identifier for the persistent actor in the backend
 durabe state store.
 
-@ref:[Cluster Sharding](cluster-sharding.md) is typically used together with `DurableStateBehavior` to ensure
+@ref:[Cluster Sharding](../cluster-sharding.md) is typically used together with `DurableStateBehavior` to ensure
 that there is only one active entity for each `PersistenceId` (`entityId`). There are techniques to ensure this 
 uniqueness, an example of which can be found in the 
-@ref:[Persistence example in the Cluster Sharding documentation](cluster-sharding.md#persistence-example). This illustrates how to construct the `PersistenceId` from the `entityTypeKey` and `entityId` provided by the `EntityContext`.
+@ref:[Persistence example in the Cluster Sharding documentation](../cluster-sharding.md#persistence-example). This illustrates how to construct the `PersistenceId` from the `entityTypeKey` and `entityId` provided by the `EntityContext`.
 
 The `entityId` in Cluster Sharding is the business domain identifier which uniquely identifies the instance of
 that specific `EntityType`. This means that across the cluster we have a unique combination of (`EntityType`, `EntityId`).
@@ -220,12 +220,12 @@ side effect is performed but that the state is not stored if the persist fails.
 
 ## Cluster Sharding and DurableStateBehavior
 
-@ref:[Cluster Sharding](cluster-sharding.md) is an excellent fit to spread persistent actors over a
+@ref:[Cluster Sharding](../cluster-sharding.md) is an excellent fit to spread persistent actors over a
 cluster, addressing them by id. It makes it possible to have more persistent actors exist in the cluster than what 
 would fit in the memory of one node. Cluster sharding improves the resilience of the cluster. If a node crashes, 
 the persistent actors are quickly started on a new node and can resume operations.
 
-The `DurableStateBehavior` can then be run as any plain actor as described in @ref:[actors documentation](actors.md),
+The `DurableStateBehavior` can then be run as any plain actor as described in @ref:[actors documentation](../actors.md),
 but since Akka Persistence is based on the single-writer principle, the persistent actors are typically used together
 with Cluster Sharding. For a particular `persistenceId` only one persistent actor instance should be active at one time.
 Cluster Sharding ensures that there is only one active entity (or actor instance) for each id. 
@@ -299,13 +299,13 @@ Java
 :  @@snip [BlogPostEntityDurableState.java](/akka-persistence-typed/src/test/java/jdocs/akka/persistence/typed/BlogPostEntityDurableState.java) { #behavior }
 
 This can be refactored one or two steps further by defining the command handlers in the state class as
-illustrated in @ref:[command handlers in the state](persistence-style-durable-state.md#command-handlers-in-the-state).
+illustrated in @ref:[command handlers in the state](persistence-style.md#command-handlers-in-the-state).
 
-There is also an example illustrating an @ref:[optional initial state](persistence-style-durable-state.md#optional-initial-state).
+There is also an example illustrating an @ref:[optional initial state](persistence-style.md#optional-initial-state).
 
 ## Replies
 
-The @ref:[Request-Response interaction pattern](interaction-patterns.md#request-response) is very common for
+The @ref:[Request-Response interaction pattern](../interaction-patterns.md#request-response) is very common for
 persistent actors, because you typically want to know if the command was rejected due to validation errors and
 when accepted you want a confirmation when the events have been successfully stored.
 
@@ -373,10 +373,10 @@ command or that a reply will be sent later, perhaps after some asynchronous inte
 
 ## Serialization
 
-The same @ref:[serialization](../serialization.md) mechanism as for actor messages is also used for persistent actors.
+The same @ref:[serialization](../../serialization.md) mechanism as for actor messages is also used for persistent actors.
 
-You need to enable @ref:[serialization](../serialization.md) for your commands (messages) and state.
-@ref:[Serialization with Jackson](../serialization-jackson.md) is a good choice in many cases and our
+You need to enable @ref:[serialization](../../serialization.md) for your commands (messages) and state.
+@ref:[Serialization with Jackson](../../serialization-jackson.md) is a good choice in many cases and our
 recommendation if you don't have other preference.
 
 ## Tagging

akka-docs/src/main/paradox/typed/index-persistence-durable-state.md

@@ -8,9 +8,9 @@ project.description: Durable state with Akka Persistence enables actors to persi
 
 @@@ index
 
-* [persistence-durable-state](persistence-durable-state.md)
-* [persistence-style](persistence-style-durable-state.md)
-* [cqrs](cqrs-durable-state.md)
-* [persistence-query](../persistence-query-durable-state.md)
+* [persistence-durable-state](durable-state/persistence.md)
+* [persistence-style](durable-state/persistence-style.md)
+* [cqrs](durable-state/cqrs.md)
+* [persistence-query](../durable-state/persistence-query.md)
 
 @@@

akka-docs/src/main/paradox/typed/persistence.md

@@ -37,7 +37,7 @@ allows for very high transaction rates and efficient replication. A stateful act
 events to the actor, allowing it to rebuild its state. This can be either the full history of changes
 or starting from a checkpoint in a snapshot, which can dramatically reduce recovery times. 
 
-Akka Persistence also supports @ref:[Durable State Behaviors](persistence-durable-state.md), which is based on 
+Akka Persistence also supports @ref:[Durable State Behaviors](durable-state/persistence.md), which is based on 
 persistence of the latest state of the actor. In this implementation, the _latest_ state is persisted, instead of events. 
 Hence this is more similar to CRUD based applications.
 

akka-persistence-query/src/main/scala/akka/persistence/query/javadsl/DurableStateStoreQuery.scala

@@ -34,7 +34,7 @@ trait DurableStateStoreQuery[A] extends DurableStateStore[A] {
    * @param offset The offset to get changes since. Must either be [[akka.persistence.query.NoOffset]] to get
    *               changes since the beginning of time, or an offset that has been previously returned by this query.
    *               Any other offsets are invalid.
-   * @return A source of change events.
+   * @return A source of change in state.
    */
   def currentChanges(tag: String, offset: Offset): Source[DurableStateChange[A], NotUsed]
 
@@ -46,14 +46,14 @@ trait DurableStateStoreQuery[A] extends DurableStateStore[A] {
    *
    * Not all changes that occur are guaranteed to be emitted, this call only guarantees that eventually, the most
    * recent change for each object since the offset will be emitted. In particular, multiple updates to a given object
-   * in quick succession are likely to be skipped, with only the last update resulting in a change event from this
+   * in quick succession are likely to be skipped, with only the last update resulting in a change from this
    * source.
    *
    * @param tag The tag to get changes for.
    * @param offset The offset to get changes since. Must either be [[akka.persistence.query.NoOffset]] to get
    *               changes since the beginning of time, or an offset that has been previously returned by this query.
    *               Any other offsets are invalid.
-   * @return A source of change events.
+   * @return A source of change in state.
    */
   def changes(tag: String, offset: Offset): Source[DurableStateChange[A], NotUsed]
 }

akka-persistence-query/src/main/scala/akka/persistence/query/scaladsl/DurableStateStoreQuery.scala

@@ -34,7 +34,7 @@ trait DurableStateStoreQuery[A] extends DurableStateStore[A] {
    * @param offset The offset to get changes since. Must either be [[akka.persistence.query.NoOffset]] to get
    *               changes since the beginning of time, or an offset that has been previously returned by this query.
    *               Any other offsets are invalid.
-   * @return A source of change events.
+   * @return A source of change in state.
    */
   def currentChanges(tag: String, offset: Offset): Source[DurableStateChange[A], NotUsed]
 
@@ -46,14 +46,14 @@ trait DurableStateStoreQuery[A] extends DurableStateStore[A] {
    *
    * Not all changes that occur are guaranteed to be emitted, this call only guarantees that eventually, the most
    * recent change for each object since the offset will be emitted. In particular, multiple updates to a given object
-   * in quick succession are likely to be skipped, with only the last update resulting in a change event from this
+   * in quick succession are likely to be skipped, with only the last update resulting in a change from this
    * source.
    *
    * @param tag The tag to get changes for.
    * @param offset The offset to get changes since. Must either be [[akka.persistence.query.NoOffset]] to get
    *               changes since the beginning of time, or an offset that has been previously returned by this query.
    *               Any other offsets are invalid.
-   * @return A source of change events.
+   * @return A source of change in state.
    */
   def changes(tag: String, offset: Offset): Source[DurableStateChange[A], NotUsed]
 }