-
Notifications
You must be signed in to change notification settings - Fork 40
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
wip: rework piece expected packages SOFIE-3402 #1258
Draft
Julusian
wants to merge
22
commits into
release52
Choose a base branch
from
feat/simplify-piece-expected-packages3
base: release52
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a very incomplete draft of how this could work.
The aim was to make a couple of key changes:
Simplify the
expectedPackages
property on pieces/adlibs/whatever, to only include a couple of ids to reference the mongo documentThis has some complications, because we then need to load documents from the collection at certain points that we didn't before. Primarily this made things complicated during playout, as we need to make a copy of any packages belonging to pieces when converting to pieceinstances, so that we can be sure the package won't disappear while still on air.
Rework the ExpectedPackages collection to avoid duplicates
Today, if piece A has a package for a clip called 'test', and piece B has the same package, this will result in two mongo documents, no matter what parts these pieces are in. This means two statuses from package-manager too.
With this change, that should become one document (per rundown). The intention is that multiple pieces can reference the same document, and we use an id derived from the content and rundownId.
Then for playout we don't need to make a copy, but just mark the document as also 'belonging' to a pieceInstance. In general this should mean that playout can skip loading the full versions of these documents, and instead only load a portion of them.
This will add complication to ingest vs playout operations, to ensure they don't remove things the other is reliant on. The common sync point of the rundownPlaylist lock will allow for coordinating this.
There is an outstanding question of whether this should be changed for buckets or not, this has not been explored yet.
Status
This has the the "Simplify the
expectedPackages
property" implemented (not tested), but perhaps broken due to later changes."Rework the ExpectedPackages collection to avoid duplicates" has been started, with the model representations being sketched out, and not yet implemented. Usages of these model changes is not fully propagated through the ingest and playout flows.
For anyone wanting to pick this up; It might be better to take inspiration from these changes instead of working from them directly.
I would be tempted to do it as follows, with each step being a separate PR:
expectedPackages
property on pieces/adlibs/related types