feat: Migration to replicated event sourcing #32438
Conversation
| es1 ! Stop | ||
|
|
||
| // then migrate to ReplicatedEventSourced, one replica must keep the same persistenceId | ||
| // as the original EventSourced, i.e. without replicaId |
There was a problem hiding this comment.
The replicaId is part of the persistenceId so I think it's easiest to let the original remain as is. I used "" as indication of such replicaId.
There was a problem hiding this comment.
Might be worth having a EmptyReplicaId or something for it
...er-sharding-typed/src/main/scala/akka/cluster/sharding/typed/ShardingDirectReplication.scala
Outdated
Show resolved
Hide resolved
| * was located should be empty. | ||
| */ | ||
| val empty: ReplicaId = ReplicaId("") | ||
| } |
There was a problem hiding this comment.
Adding this companion makes mima complain:
[error] akka-persistence-typed: Failed binary compatibility check against com.typesafe.akka:akka-persistence-typed_2.13:2.6.12! Found 3 potential problems (filtered 18)
[error] * static method andThen(scala.Function1)scala.Function1 in class akka.persistence.typed.ReplicaId does not have a correspondent in current version
[error] filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("akka.persistence.typed.ReplicaId.andThen")
[error] * static method compose(scala.Function1)scala.Function1 in class akka.persistence.typed.ReplicaId does not have a correspondent in current version
[error] filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("akka.persistence.typed.ReplicaId.compose")
[error] * the type hierarchy of object akka.persistence.typed.ReplicaId is different in current version. Missing types {scala.runtime.AbstractFunction1}
[error] filter with: ProblemFilters.exclude[MissingTypesProblem]("akka.persistence.typed.ReplicaId$")
Strange, I thought that wouldn't be a problem. What shall I do? Add mima filter? Rename to object EmptyReplicaId?
There was a problem hiding this comment.
Huh, yeah maybe best to make a separate case object.
There was a problem hiding this comment.
huh, huh, and that doesn't work because can't extend final case class, and extending a case class is not good in the first place
There was a problem hiding this comment.
Ok, so can we just implement the apply and extend AbstractFunction1 then and fulfil the existing contract?
There was a problem hiding this comment.
Added AbstractFunction1 to the companion.
Refs #29261