Skip to content
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

Coping with changes to showing times #9

Open
andrewferguson opened this issue Nov 4, 2021 · 0 comments
Open

Coping with changes to showing times #9

andrewferguson opened this issue Nov 4, 2021 · 0 comments

Comments

@andrewferguson
Copy link
Collaborator

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:

  1. ShowingPreviously archives the showings before the change in time, recording a showing at 18:00
  2. 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant