You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider the case where a cinema needs to alter the showing time of a film, for example changing the showing time of a film from 18:00 to 18:30 (on the same day). What is likely to happen is as follows:
ShowingPreviously archives the showings before the change in time, recording a showing at 18:00
Later, ShowingPrevously archives the showings after the change in time, recording a showing at 18:30
Now we have two showings recorded in the database, despite there being only one showing in the cinema. This is undesirable.
Of course, the most accurate (and simplest) way of achieving this would be to archive the showing times once the showing had started. Unfortunately, most cinemas do not provide historical showing information, even for a few days. Another method would be to minimise the "look-ahead", preventing the archiver from recording a showing if it occurs too far into the future. But this will require running the archiver more frequently, which becomes more impractical as the number of chains supported increases.
One option that I can think of is that an additional column is added to the Showings table, recording the "run" of ShowingPreviously that resulted in the showing being added. (In other words, all the showings added during a single execution of ShowingPreviously would have the same "run" ID). It would then be possible, on a per-screen (or perhaps per-cinema if we want to detect changes in screens as well as times) basis to compare the results of the most recent execution with the past execution, to see what the changes are, and to try and identify changes in time / screen / etc... (and perhaps even other changes such as cancelled screenings).
The text was updated successfully, but these errors were encountered:
Consider the case where a cinema needs to alter the showing time of a film, for example changing the showing time of a film from 18:00 to 18:30 (on the same day). What is likely to happen is as follows:
Now we have two showings recorded in the database, despite there being only one showing in the cinema. This is undesirable.
Of course, the most accurate (and simplest) way of achieving this would be to archive the showing times once the showing had started. Unfortunately, most cinemas do not provide historical showing information, even for a few days. Another method would be to minimise the "look-ahead", preventing the archiver from recording a showing if it occurs too far into the future. But this will require running the archiver more frequently, which becomes more impractical as the number of chains supported increases.
One option that I can think of is that an additional column is added to the
Showings
table, recording the "run" of ShowingPreviously that resulted in the showing being added. (In other words, all the showings added during a single execution of ShowingPreviously would have the same "run" ID). It would then be possible, on a per-screen (or perhaps per-cinema if we want to detect changes in screens as well as times) basis to compare the results of the most recent execution with the past execution, to see what the changes are, and to try and identify changes in time / screen / etc... (and perhaps even other changes such as cancelled screenings).The text was updated successfully, but these errors were encountered: