From c9b8ebaffd8f6f90a956f716ca05a94319fde368 Mon Sep 17 00:00:00 2001 From: Alden Torres Date: Wed, 20 Mar 2019 18:49:19 -0400 Subject: [PATCH] minor fix in docs and import cleanup (#1815) --- docs/manual/java/guide/cluster/PersistentEntity.md | 2 +- docs/manual/scala/guide/cluster/PersistentEntity.md | 2 +- .../scaladsl/persistence/cassandra/CassandraReadSide.scala | 2 +- .../lightbend/lagom/internal/persistence/ReadSideConfig.scala | 1 - 4 files changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/manual/java/guide/cluster/PersistentEntity.md b/docs/manual/java/guide/cluster/PersistentEntity.md index ae7361f831..6b9af2144d 100644 --- a/docs/manual/java/guide/cluster/PersistentEntity.md +++ b/docs/manual/java/guide/cluster/PersistentEntity.md @@ -235,5 +235,5 @@ This needs a deeper explanation to understand the guarantees provided by Lagom. If you are familiar with [Akka Persistence](https://doc.akka.io/docs/akka/2.5/persistence.html) this process is slightly different in few places: * new commands are not processed until events are stored, the `Effect` completed and the snapshot updated (if necessary). Akka provides the same behavior and also `async` alternatives that cause new commands to be processed even before all event handlers have completed. -* saving snapshots is an operation run under the covers _at least_ every `lagom.persistence. snapshot-after` events (see [Configuration](#Configuration) above) but "storing events atomically" takes precedence. Imagine we want a snapshot every 100 events and we already have 99 events, if the next command emits 3 events the snapshot will only be stored after event number 102 because events `[100, 101, 102]` will be stored atomically and only after it'll be possible to create a snapshot. +* saving snapshots is an operation run under the covers _at least_ every `lagom.persistence.snapshot-after` events (see [Configuration](#Configuration) above) but "storing events atomically" takes precedence. Imagine we want a snapshot every 100 events and we already have 99 events, if the next command emits 3 events the snapshot will only be stored after event number 102 because events `[100, 101, 102]` will be stored atomically and only after it'll be possible to create a snapshot. diff --git a/docs/manual/scala/guide/cluster/PersistentEntity.md b/docs/manual/scala/guide/cluster/PersistentEntity.md index 653288471a..26d579c6e6 100644 --- a/docs/manual/scala/guide/cluster/PersistentEntity.md +++ b/docs/manual/scala/guide/cluster/PersistentEntity.md @@ -237,5 +237,5 @@ This needs a deeper explanation to understand the guarantees provided by Lagom. If you are familiar with [Akka Persistence](https://doc.akka.io/docs/akka/2.5/persistence.html) this process is slightly different in few places: * new commands are not processed until events are stored, the `Effect` completed and the snapshot updated (if necessary). Akka provides the same behavior and also `async` alternatives that cause new commands to be processed even before all event handlers have completed. -* saving snapshots is an operation run under the covers _at least_ every `lagom.persistence. snapshot-after` events (see [Configuration](#Configuration) above) but "storing events atomically" takes precedence. Imagine we want a snapshot every 100 events and we already have 99 events, if the next command emits 3 events the snapshot will only be stored after event number 102 because events `[100, 101, 102]` will be stored atomically and only after it'll be possible to create a snapshot. +* saving snapshots is an operation run under the covers _at least_ every `lagom.persistence.snapshot-after` events (see [Configuration](#Configuration) above) but "storing events atomically" takes precedence. Imagine we want a snapshot every 100 events and we already have 99 events, if the next command emits 3 events the snapshot will only be stored after event number 102 because events `[100, 101, 102]` will be stored atomically and only after it'll be possible to create a snapshot. diff --git a/persistence-cassandra/scaladsl/src/main/scala/com/lightbend/lagom/scaladsl/persistence/cassandra/CassandraReadSide.scala b/persistence-cassandra/scaladsl/src/main/scala/com/lightbend/lagom/scaladsl/persistence/cassandra/CassandraReadSide.scala index eead9760a4..5b2fce94b5 100644 --- a/persistence-cassandra/scaladsl/src/main/scala/com/lightbend/lagom/scaladsl/persistence/cassandra/CassandraReadSide.scala +++ b/persistence-cassandra/scaladsl/src/main/scala/com/lightbend/lagom/scaladsl/persistence/cassandra/CassandraReadSide.scala @@ -15,7 +15,7 @@ import scala.reflect.ClassTag /** * Cassandra read side support. * - * This should be used to build and register readside + * This should be used to build and register a read side processor. */ object CassandraReadSide { diff --git a/persistence/core/src/main/scala/com/lightbend/lagom/internal/persistence/ReadSideConfig.scala b/persistence/core/src/main/scala/com/lightbend/lagom/internal/persistence/ReadSideConfig.scala index 462d4ff10c..3bc6cf61fb 100644 --- a/persistence/core/src/main/scala/com/lightbend/lagom/internal/persistence/ReadSideConfig.scala +++ b/persistence/core/src/main/scala/com/lightbend/lagom/internal/persistence/ReadSideConfig.scala @@ -6,7 +6,6 @@ package com.lightbend.lagom.internal.persistence import java.util.concurrent.TimeUnit import com.typesafe.config.Config -import play.api.Configuration import scala.concurrent.duration._