Skip to content
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

Merged
merged 6 commits into from
Sep 6, 2019
Merged

CRDT Serialization #92

merged 6 commits into from
Sep 6, 2019

Conversation

ktoso
Copy link
Member

@ktoso ktoso commented Sep 4, 2019

Serializers and infra for CRDT Serialization

If merging, please rebase merge, co creds remain for Yim's initial work

Motivation:

Modifications:

Result:

  • serializable .write message as well as core CRDT types including GCounter and ORSet

@ktoso
Copy link
Member Author

ktoso commented Sep 4, 2019

I'll rebase/squash now, though now lunch :)

@ktoso ktoso requested review from yim-lee and drexin September 4, 2019 10:48
Copy link
Member

@drexin drexin left a 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/CRDT+Replication.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 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use map instead?

Copy link
Member Author

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"?

/// 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) {
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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? :)

Copy link
Member Author

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...

Copy link
Member Author

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 🤔

Copy link
Member

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
}

@ktoso
Copy link
Member Author

ktoso commented Sep 5, 2019

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.

@ktoso ktoso requested a review from drexin September 5, 2019 06:20
@ktoso
Copy link
Member Author

ktoso commented Sep 5, 2019

Failure was #17, tied to investigate

@ktoso
Copy link
Member Author

ktoso commented Sep 5, 2019

@swift-server-bot test this please

@drexin
Copy link
Member

drexin commented Sep 5, 2019

#98

03:24:59 Test Case 'VersionVectorTests.test_Dot_sort_shouldBeByReplicaThenByVersion' started at 2019-09-05 10:24:59.586
03:24:59 /code/Tests/DistributedActorsTests/Clocks/VersionVectorTests.swift:194: error: VersionVectorTests.test_Dot_sort_shouldBeByReplicaThenByVersion : XCTAssertEqual failed: ("[dot:(actor:/user/B,1), dot:(actor:/user/B,2), dot:(actor:/user/A,3), dot:(actor:/user/C,5)]") is not equal to ("[dot:(actor:/user/A,3), dot:(actor:/user/B,1), dot:(actor:/user/B,2), dot:(actor:/user/C,5)]") - 
03:24:59         sortedDots.shouldEqual([dot2, dot3, dot1, dot4])
03:24:59                    ^~~~~~~~~~~~
03:24:59 error: [[dot:(actor:/user/B,1), dot:(actor:/user/B,2), dot:(actor:/user/A,3), dot:(actor:/user/C,5)]] does not equal expected: [[dot:(actor:/user/A,3), dot:(actor:/user/B,1), dot:(actor:/user/B,2), dot:(actor:/user/C,5)]]
03:24:59 
03:24:59 Test Case 'VersionVectorTests.test_Dot_sort_shouldBeByReplicaThenByVersion' failed (0.004 seconds)
03:24:59 Test Suite 'VersionVectorTests' failed at 2019-09-05 10:24:59.589
03:24:59 	 Executed 8 tests, with 1 failure (0 unexpected) in 0.194 (0.194) seconds
03:24:59 Test Suite 'WorkerPoolTests' started at 2019-09-05 10:24:59.589

@yim-lee
Copy link
Member

yim-lee commented Sep 5, 2019

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.

Don't worry. I won't be offended if my commit were squashed.

@yim-lee
Copy link
Member

yim-lee commented Sep 5, 2019

Looking through this. Please hold off merging.

Done. Thanks.

@drexin
Copy link
Member

drexin commented Sep 5, 2019

@yim-lee Credit where credit is due :).

@drexin
Copy link
Member

drexin commented Sep 5, 2019

@swift-server-bot test this please

Copy link
Member

@yim-lee yim-lee left a 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.

@ktoso
Copy link
Member Author

ktoso commented Sep 6, 2019

Thanks for review! Looking at it :)

yim-lee and others added 6 commits September 6, 2019 15:39
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
@ktoso
Copy link
Member Author

ktoso commented Sep 6, 2019

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.

@ktoso ktoso merged commit 1870e04 into apple:master Sep 6, 2019
@yim-lee
Copy link
Member

yim-lee commented Sep 6, 2019

perhaps let's clean anything I've messed up on those in a follow up PR

Yep, thanks @ktoso for your help. I will pick up from this next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants