-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRDT Serialization #92
Conversation
I'll rebase/squash now, though now lunch :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Publishing the partial review and continue later.
Sources/DistributedActors/CRDT/Protobuf/CRDT+Serialization.swift
Outdated
Show resolved
Hide resolved
self.vv = try .init(fromProto: proto.versionVector, context: context) | ||
self.gaps = [] | ||
self.gaps.reserveCapacity(proto.gaps.count) | ||
for versionDot in proto.gaps { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use map
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm can't on this one since typemismatch, or I'd have to first make the thing to a Set<>
not sure if that's "free"?
Sources/DistributedActors/CRDT/Protobuf/CRDT+Serialization.swift
Outdated
Show resolved
Hide resolved
Sources/DistributedActors/CRDT/Protobuf/CRDTEnvelope+Serialization.swift
Outdated
Show resolved
Hide resolved
Sources/DistributedActors/CRDT/Protobuf/CRDTEnvelope+Serialization.swift
Outdated
Show resolved
Hide resolved
/// MUST NOT be invoked after initialization of serialization. // TODO: enforce this perhaps? Or we'd need concurrent maps otherwise... should be just a set-once thing tbh | ||
// TODO: Not sure if there is a way around this, or something similar, as we always need to make the id -> type jump eventually. | ||
// FIXME: We should not need this; It's too complex for end users (having to call "random" boxings when they register a type does not sound sane | ||
public mutating func registerBoxing<M, Box>(from messageType: M.Type, into boxType: Box.Type, _ boxer: @escaping (M) -> Box) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to spend some time understanding this. Will continue here later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caught up on chat, seems decision is to revisit as swift painpoint and seek help during review. For now it unlocks us at least.
We could also change our messages to avoid erasure, though question is if that's the answer for our users or not.
FYI @yim-lee
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok 👍
revisit as swift painpoint
What would the pain-point be?
We could also change our messages to avoid erasure
If we could use CvRDT
as type rather than just generic constraint. Would that be considered a pain-point? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would the pain-point be?
I made it into a ticket #91
I think what would work is if we were able to ask "for any ORSet" but we can't do this since ObjectIdentifier of a type is always the ORSet<OfSomething>
; I think if we could check this then we could automatically run the "box it using the thing" code... 🤔 Have not made sure yet...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also change our messages to avoid erasure
If we could use CvRDT as type rather than just generic constraint. Would that be considered a pain-point? :)
So... then we would not have to do any of the boxing at all right? I guess that would help then 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add an untyped interface in between and register that for serialization? That could then have a property that's the MetaType of the contained type. I.e.
protocol _ORSet {
var elementMetaType: AnyMetaType
}
Addressed review; Watch out when merging though; this is best merged as a rebase or manually squashing things when doing so, so we keep @yim-lee's commit separate. |
Failure was #17, tied to investigate |
@swift-server-bot test this please |
|
Don't worry. I won't be offended if my commit were squashed. |
Done. Thanks. |
@yim-lee Credit where credit is due :). |
@swift-server-bot test this please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much @ktoso. I think this approach is much cleaner. There might be some confusion around AnyCvRDT
and AnyDeltaCRDT
(they both represent full CRDT), but not a deal-breaker.
Tests/DistributedActorsTests/CRDT/Protobuf/CRDT+SerializationTests.swift
Show resolved
Hide resolved
Tests/DistributedActorsTests/CRDT/Protobuf/CRDT+SerializationTests.swift
Outdated
Show resolved
Hide resolved
Tests/DistributedActorsTests/CRDT/Protobuf/CRDT+SerializationTests.swift
Outdated
Show resolved
Hide resolved
Tests/DistributedActorsTests/CRDT/Protobuf/CRDTReplication+SerializationTests.swift
Show resolved
Hide resolved
Tests/DistributedActorsTests/CRDT/Protobuf/CRDTReplication+SerializationTests.swift
Outdated
Show resolved
Hide resolved
Thanks for review! Looking at it :) |
Motivation: For direct replication (#27) we need to send CRDTs to remote replicators, therefore they need to be serializable. Modifications: - Define protobufs for CRDTs and conform to `InternalProtobufRepresentable`. - Define protobufs for `CRDT.Replicator.RemoteCommand`. - Special handling in `Serialization` for CRDT serializers. Result: Be able to send `CRDT.Replicator.RemoteCommand` message to remote replicators.
access serializer internally without exposing collection
make boxing a first class citizen, and use for AnyCRDTs formatting +crdt,ser carry delta in serialized gcounters
Allow for ORSet<Int> and test Replicator write containing ORSet
The failure will be fixed in #103 Thanks for review, let's keep moving with the CRDTs :) I'm a bit confused about #92 (comment) perhaps let's clean anything I've messed up on those in a follow up PR next week? Hope that's okey. |
Yep, thanks @ktoso for your help. I will pick up from this next week. |
Serializers and infra for CRDT Serialization
Motivation:
Modifications:
Result:
.write
message as well as core CRDT types includingGCounter
andORSet