Change type of event duration in DB from i32 to i64 #986
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
A recent change to the Tobira module in OC changed how durations are acquired. Before, the duration of our "always live" events was reported as 0. But now the "correct" duration is reported, i.e. the difference between start and end time. That's many years. 2^31 ms are roughly 25 days. So this broke for our live events. Note that I had to really try convince Opencast of even creating this live event with more than 24h between start and end time. So I would bet that out there, there is no Opencast event longer than 25 days. Unfortunately, Juniper does not support i64 as scalar type. That's partially ... correct. JSON does in principle only support f64 numbers as that's what JS is using. But since JSON is text and the numbers are decimal numbers, no one stops you from writing a number to JSON that is not representable as f64. And apparently this is sometimes done. Either way, we now cast the i64 to f64 for the API. Note that f64 can exactly represent integers up to 2^53. That in ms is 285 thousand years. Also note that the duration from Opencast is also transmitted to us via JSON. So while this whole situation is not ideal, it's healthy to remember that basically no event out there will ever run into this situation and I there are no real world events for which the "i64 to f64" conversion is not exact. I am also aware that our live streams currently say "Duration 2431753:00:00". But let's not worry about this. If there are actual uses of >24h events out there, we can still improve that part.
owi92
approved these changes
Nov 8, 2023
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.
A recent change to the Tobira module in OC changed how durations are acquired. Before, the duration of our "always live" events was reported as 0. But now the "correct" duration is reported, i.e. the difference between start and end time. That's many years. 2^31 ms are roughly 25 days. So this broke for our live events. Note that I had to really try convince Opencast of even creating this live event with more than 24h between start and end time. So I would bet that out there, there is no Opencast event longer than 25 days.
Unfortunately, Juniper does not support i64 as scalar type. That's partially ... correct. JSON does in principle only support f64 numbers as that's what JS is using. But since JSON is text and the numbers are decimal numbers, no one stops you from writing a number to JSON that is not representable as f64. And apparently this is sometimes done. Either way, we now cast the i64 to f64 for the API. Note that f64 can exactly represent integers up to 2^53. That in ms is 285 thousand years. Also note that the duration from Opencast is also transmitted to us via JSON.
So while this whole situation is not ideal, it's healthy to remember that basically no event out there will ever run into this situation and I there are no real world events for which the "i64 to f64" conversion is not exact.
I am also aware that our live streams currently say "Duration 2431753:00:00". But let's not worry about this. If there are actual uses of >24h events out there, we can still improve that part.