Add playlists to sync code, DB & API and add playlist direct links #1159
Conversation
a7b1948 to
8f64bb9
Compare
I guess you mean "... that the user has no read access to.", right? For us (University of Bern): No. But since having the merge mode activated, all events of the same series have the same ACLs we might not be the right institution to answer this question.
What about: "Manually (Playlist order)" (en) / "Manuell (wie Playlist)" (de) oder nur "Manually/Manuell"? |
|
Thanks, Lukas. I was surprised to see this:
Two things make me think we should not let them do this (at the moment):
As to your questions:
|
Yes, you are correct! Fixed.
I think there are two reasons I already implemented this:
Regarding "missing note": Bern says "no", ETH says "yes", but both actually don't care. So I will just keep it as is and not invest time there now :P |
This comment was marked as resolved.
This comment was marked as resolved.
|
Let me get this straight: If I create a playlist, will users be able to change the order, thus making it a collection (from his/her perspective)? Or is there an alternative to create a collection? |
Yes, they can locally change the display order only for themselves. |
|
And your reasoning is that playlists are only a suggestion to watch in a given order anyway? |
8f64bb9 to
eb1f9c2
Compare
|
Rebased, solving the merge conflicts. Remaining open points: Wording playlist order
I am not a big fan of David's long suggestion, simply because they are pretty long. I also don't really like "manually" as it's note immediately clear who did/can do something manually where. Just "Playlists" is fine, but I think the current version is slightly better as it suggests being about "ordering" in itself, even without opening the menu and seeing the "Order" heading. So I would just keep the current version for now, if no one objects? Please note though that my opinion is not strong at all here, and I gladly change it if someone with a stronger opinion speaks up.
We discussed this in person and concluded that indeed it doesn't hurt to let users change the order for themselves in this case. Assuming no one objects to the points above, I think this is ready. I will now try to update our test Opencast to support playlists. |
This comment was marked as resolved.
This comment was marked as resolved.
eb1f9c2 to
1534b45
Compare
a6868fe to
2a2a885
Compare
This comment was marked as resolved.
This comment was marked as resolved.
2a2a885 to
5ab010d
Compare
5ab010d to
3244bc0
Compare
This comment was marked as resolved.
This comment was marked as resolved.
3244bc0 to
20ac583
Compare
20ac583 to
edb1297
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This means that Tobira will store all playlist info already when
syncing.
I thought about the DB "array vs. table" question for some time. Here
are my notes that made me decide for the array solution:
Should the entries be stored as an array in a column of the `playlists`
table? Or be a separate table that needs to be joined? The latter would
be the traditionally "better" version, as it normalizes the data.
A playlist entry contains these fields:
- Opencast ID,
- Type (e.g. video)
- Content ID (e.g. Opencast video ID).
If we store it in a separate table we also need the following fields:
- Playlist: foreign key to playlist ID
- Index: ordering in a table is not well defined, so to get a definite
order, we need another index field.
- Potentially another artificial ID?
- Normalization is what you're supposed to do, right?
- Allows to use LIMIT and OFFSET, i.e. only load part of all entries.
(Kind of possible with arrays as well though).
- Allows to modify/delete individual entries without rewriting all of
them
- Many situations treat the entries as one atomic value:
- Harvest/sync: the API sends the full playlist object including
entries. If using an extra table, we would have to delete all old
entries there, then insert all new ones.
- Playlist block: loads all entries. Ok but what about pagination:
we don't have that yet. But we should at some point?
- Even in the modifying/moving/deleting a single entry case:
- Opencast's APIs require us to send all entries, so while we
can do very localized updates in our DB, we have to load all
entries anyway.
- After changing something, the Harvest API will send an update
which leads to overwriting all entries again.
- Extra table requires at least two additional fields to be stored
(foreign key & index)
- Management of `index` adds complexity whenever somehow editing
entries. Just writing all entries at once again is easier. Also:
should there be DB checks that make sure the indices are always 0 to
N like for blocks? Adds more complexity and we ran into problems with
that once.
- Even if we add pagination: apart from offering a different UX,
pagination helps with performance in four spots: rendering,
backend<->frontend communication, DB<->backend communication, DB
loading from disk. The first three benefits we can still have, even
with arrays.
- Looking at how PostgreSQL stores rows, arrays shouldn't incur any
meaningful overhead and might even be faster in the majority of
situations.
We did not have types depending on other types before. Adding "cascade" luckily fixes this.
I only moved stuff around and fixed imports, that's all. I did that so that the reviewer can just skip this commit. It is preparation for making a general `VideoListBlock`.
Again, preparation for using that for playlists as well
This was added a long time ago. By now, the ordering is done in the frontend, so the parameter is completely unused. We can get rid of some complexity by removing it.
This only adds querying capabilities, no mutations yet.
This is a band aid fix and not perfect. When I added the `Unknown`
variant to the enum, I wasn't aware that it was used when other variants
fail to deserialize even with `kind: "event"`. So the warning there
was misleading.
It's still not perfect because I ideally want to print more information
on the deseralization failure. And the `kind` strings are duplicated
now. I think in the future, the `HarvestResponse` might have items of
type `{ kind: String, #[serde(flatten)] body: serde_json::Value }` or
something like that. And then we deserialize it manually in a second
step. We will see.
edb1297 to
ece4812
Compare
There was a problem hiding this comment.
Lgtm 👍
For anyone else watching this and just to reiterate: As Lukas mentioned in the top comment, this does not let you create/edit Playlists or add them as blocks yet. The former is still tbd while the latter is implemented in #1181
This builds on #1159 to add the necessary components and adjustments in both back- and frontend to allow creating and editing playlist **blocks**. These are already a lot of changes, so in order to limit the scope of this PR and make it somewhat reviewable, a feature _still_ missing is a management area to create, delete and edit playlists themselves (i.e. adding and removing videos).
This is the first PR about playlists for Tobira. It requires opencast/opencast#5734 to be useful.
This does mainly two things:
Two main features are still missing:
For these two, I will create separate issues. Therefore:
Closes #937
Screenshots
Unfortunately, there are no playlists on the test deployment yet. So here are some screenshots:
As you can see:
Open questions
Can be reviewed commit by commit.