-
Notifications
You must be signed in to change notification settings - Fork 57
[v2.0] Branch Announcement Message #262
[v2.0] Branch Announcement Message #262
Conversation
… v2.0/branch-announcement
… v2.0/branch-announcement
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.
Looking very good. Just a couple of things that I find missing, and I think we could have them in this same PR so that we can consider this functionality done already.
streams/src/api/user.rs
Outdated
// handling the message | ||
self.state | ||
.cursor_store | ||
.insert_cursor(&topic, publisher.clone(), INIT_MESSAGE_NUM); |
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.
This still won't "carry over" the permissions of the parent branch to the new branch. Do we want to implement it in this PR, or create a new one for this functionality? It essentially mean to get all cursors tracked in parent branch and init them in the new branch. Without having given it much thought, sounds easy enough to do it in this PR. It would require implementing some testing in the examples though, which might take a bit more time
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.
Probably reasonable to do that yeah. I'll look at implementing it in this PR.
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.
After some work/thought I think a different PR makes more sense.
// If a message has been sent successfully, insert the base branch into store | ||
self.state.cursor_store.new_branch(topic.clone()); | ||
// Commit message to stores | ||
self.state |
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.
624-630 happen in here, handle_announcement
and in handle_branch_announcement
. Maybe we should make a method?
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.
Wouldn't hurt
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.
After examining it more closely I'm not sure that would work. When handling messages we store the cursor before unwrapping the message, and then store spongos if it was successful, whereas on sending we store the cursor and spongos one after another after the message sends properly.
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, from my side it's a go! This last comment can be addressed now, or when we implement the advanced message consumption
streams/src/api/user.rs
Outdated
// Collect permissions from previous branch and clone them into new branch | ||
let prev_permissions = self | ||
.cursors() | ||
.filter(|cursor| cursor.0 == &prev_topic) |
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.
This iterates the potentially very long set of all cursors in the StreamCan, just to filter those of an specific topic. We could easily have a (&Topic) -> impl Iterator<Item=(&Identifier, usize)>
method that uses the HashMap
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.
Alright I added the function, just let me know if there's another change you want done to it, otherwise I'm ready to merge it whenever
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.
Yes LGTM, lets merge @arnauorriols
Description of change
Adds a new
BranchAnnouncement
type message that conveys linked and newTopic
details. Separates the announcement logic intoStreamAnnouncement
andBranchAnnouncement
.Addresses #258
Type of change
How the change has been tested
BranchAnnouncement
messages while fetchingMessages
testfmt
andclippy