-
Notifications
You must be signed in to change notification settings - Fork 276
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
Modeling exercises
: Improve synchronization of team-based exercises
#8078
Modeling exercises
: Improve synchronization of team-based exercises
#8078
Conversation
Modeling exercises
: sync team-based modeling exercises using apollon's patch-based collaboration
There hasn't been any activity on this pull request recently. Therefore, this pull request has been automatically marked as stale and will be closed if no further activity occurs within seven days. Thank you for your contributions. |
WalkthroughThis update introduces enhancements and reformatting across multiple components of a Spring Boot project, focusing on collaborative editing features for modeling submissions. Notably, it adds support for JSON Patch operations, enabling real-time updates and synchronization between team members' submissions. The changes span from backend Java classes, including new DTOs for submission patches, to frontend Angular components, improving the user experience in collaborative exercises. Additionally, some configuration files and dependencies have been updated to support these new features. Changes
Possibly related issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
src/main/java/de/tum/in/www1/artemis/web/websocket/team/ParticipationTeamWebsocketService.java
Outdated
Show resolved
Hide resolved
src/main/java/de/tum/in/www1/artemis/web/websocket/team/ParticipationTeamWebsocketService.java
Outdated
Show resolved
Hide resolved
src/main/java/de/tum/in/www1/artemis/domain/SubmissionPatch.java
Outdated
Show resolved
Hide resolved
src/main/webapp/app/exercises/shared/team-submission-sync/team-submission-sync.component.ts
Outdated
Show resolved
Hide resolved
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.
Thank you for the explanation it is now more clear to me how Apollon works.
Re-tested on TS2 and worked well 👍
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.
Re-tested on TS2 worked well, thanks for the fix. Code lgtm
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, looks good, I just added two minor code style suggestions
* @param arg | ||
*/ | ||
export function isSubmissionPatchPayload(arg: any): arg is SubmissionPatchPayload { | ||
return arg.submissionPatch !== undefined && arg.sender !== undefined; |
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.
return arg.submissionPatch !== undefined && arg.sender !== undefined; | |
return Boolean(arg.submissionPatch && arg.sender); |
@@ -5,3 +5,7 @@ export class SubmissionSyncPayload { | |||
public submission: Submission; | |||
public sender: User; | |||
} | |||
|
|||
export function isSubmissionSyncPayload(arg: any): arg is SubmissionSyncPayload { | |||
return arg.submission !== undefined && arg.sender !== undefined; |
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.
return arg.submission !== undefined && arg.sender !== undefined; | |
return Boolean(arg.submission && arg.sender); |
@@ -97,10 +98,11 @@ export class ModelingSubmissionComponent implements OnInit, OnDestroy, Component | |||
examMode = false; | |||
|
|||
// submission sync with team members | |||
teamSyncInterval: number; |
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.
👍
867ed7d
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.
Re-approve
Checklist
General
Server
Client
Motivation and Context
In team-based modelling exercises, when multiple team members are working on the same UML diagram, the diagram is synchronised naively: peers exchange their local diagrams wholesale and one diagram wins, overriding all unsynced changes by other peers.
Description
This PR solves the aforementioned issue by using Apollon's patch-based realtime collaboration mechanism, where peers exchanges patches reflecting their recent local changes instead of whole diagrams, and reaching an eventually consistent state by applying said patches to their local state. All patches are in the standard JSONPatch format.
The server doesn't partake in the conflict resolution process except for determining the definite timeline of patches by re-emitting them to all clients, keeping the server code simple and straight-forward.
Patch-based communication also allows for continuous synchronisation between clients e.g. during movement of an element. While exchanging diagrams wholesale, continuous sync would effectively only allow one peer to modify the diagram, while with patch-based sync peers can simultaneously work on different parts of the diagram while seeing the work of their peers update in realtime.
The process for "saving" submissions in a team-based exercise remains unchanged: the clients check for changes on a routine interval and ask the server to save the whole diagram. The only change in this regard is that the server DOES NOT sync the diagram between team-members upon saving, to avoid resetting local work of each member (syncing is done via patches). This keeps the server-side logic simple as the server does not need to parse submissions and patch models (which also would require some debouncing mechanism on the server side).
Steps for Testing
Prerequisites:
Testserver States
Note
These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Review Progress
Performance Review
Code Review
Manual Tests
Test Coverage
Client
Server
Screenshots
Summary by CodeRabbit
zjsonpatch
for JSON patch operations.