Make default persistent entity offset Long

[jroper]

The current PersistentEntityRegistry API is specific to Cassandra, since it uses UUID for offsets, where Akka persistence only requires the use of Long.

This change moves the UUID version of the method to a new CassandraPeristentEntityRegistry trait, deprecates the existing method, and creates a new version of the method that uses Long offsets.

In order to keep the change binary compatible, the new method switches the order of parameters around. That's not entirely ideal, since it probably makes more sence to have the startFrom parameter second. However, I couldn't think of a better way, I think eventStream is the best name. I'm open to suggestions if someone can think of a better name or strategy to maintain binary compatibility.

[patriknw]

change package to com.lightbend.lagom.internal.persistence.cassandra, where other Cassandra specific classes are located

[jroper]

Done.

[patriknw]

This requires careful documentation for the semantics of the offset compared to the UUID version. Inclusive vs exclusive. See scaladoc here https://github.com/akka/akka-persistence-cassandra/blob/master/src/main/scala/akka/persistence/cassandra/query/scaladsl/CassandraReadJournal.scala#L232 and https://github.com/akka/akka-persistence-cassandra/blob/master/src/main/scala/akka/persistence/cassandra/query/scaladsl/CassandraReadJournal.scala#L276

[jroper]

@patriknw Using UUID for everything, and converting them to and from longs, introduces a problem in that the same event will have multiple different UUIDs every time it's loaded, since when you convert a long to a UUID, you have to fill in the rest of the bits, which the datastax library fills in with node specific information and a local sequence number, in accordance with the UUID spec. The other problem with it is that it's an incorrect use of UUID - the long from other persistence journals is typically a sequence number, not a timestamp. UUIDs have several different modes which place significance on their components, and applications often use this, so if an application sees that it's a timestamp, when it's actually a sequence number, it's going to end up extracting a timestamp that will be completely wrong.

Polymorphic offset types offer a convenient API, the biggest drawback I can see is that our offset tables will need two columns to store it, a uuid column and a long column, and will have to decide which it is based on which one is not null.

[jroper]

Actually I'm wrong about the multiple different UUIDs, the UUIDs.startOf method will return the same UUID for the same timestamp. But as the library says, these are "fake" UUIDs, since they are not unique, which is just as bad, if not worse, than the other problem, the whole point of UUIDs is you can always assume they are unique, not just for a given entity type, but across all entities on every system everywhere. Passing out non unique UUIDs is a big problem.

[jroper]

Ok, I've updated this to be polymorphic. I've been very strict, the types must strictly be an offset type, that means the UUID must be a time-based UUID (version 1), since that's the only type of UUID that can be used for an offset, and this is enforced. And the long must be a Sequence. There is no conversion of sequences to time based UUIDs since this doesn't make sense - the two types are not comparable in any way and can't be converted in a way that doesn't violate each others rules.

So, Cassandra will only consume and produce UUID offsets, it will fail if it sees a long based sequence, since it doesn't support sequence numbers for offsets. I think this is the best and safest way to implement things.

[patriknw]

reuse Long.hashCode(value)

[patriknw]

Sorry if I confused you with the conversion thoughts. I agree, and what you have implemented is exactly what I had in mind with the Offset type.

LGTM

[patriknw]

Perhaps we can actually change the api of the persistence query eventsByTag api to use something like this. I have previously not wanted to do that because I only saw Any as the possible type, but with a few predefined Offset types it makes more sense.