0.2.78
This commit is contained in:
@@ -577,6 +577,17 @@ CREATE TABLE IF NOT EXISTS media_requests (
|
||||
PRIMARY KEY (emby_user_id, media_type, foreign_id)
|
||||
);
|
||||
|
||||
-- last_status is the one piece of request state that *is* stored, and only because a
|
||||
-- transition cannot be derived from a single read. Everything else on a request card is
|
||||
-- computed per read from the *arrs and the library; "it has just become ready" is not a
|
||||
-- property of the present, it is the difference between two observations, and the viewer
|
||||
-- has to be told about it exactly once.
|
||||
--
|
||||
-- It is seeded when the request is recorded rather than left blank for a sweep to fill in,
|
||||
-- because a film that downloads in the three minutes before the first sweep would otherwise
|
||||
-- have its arrival recorded as its opening state and nobody would ever be told.
|
||||
ALTER TABLE media_requests ADD COLUMN IF NOT EXISTS last_status TEXT NOT NULL DEFAULT '';
|
||||
|
||||
CREATE INDEX IF NOT EXISTS media_requests_user_requested_idx
|
||||
ON media_requests (emby_user_id, requested_at DESC);
|
||||
|
||||
@@ -663,6 +674,28 @@ CREATE TABLE IF NOT EXISTS scheduled_task_runs (
|
||||
error TEXT NOT NULL DEFAULT ''
|
||||
);
|
||||
|
||||
-- Which integration a run belongs to, and what it actually did.
|
||||
--
|
||||
-- Deliberately more columns on this table rather than a second one: an integration run IS
|
||||
-- a scheduled task run, read with a different question in mind. Operations history and
|
||||
-- "what does the gateway do in the background" are the same rows; giving integrations
|
||||
-- their own table would mean two schedulers, two retention jobs and two places a run can
|
||||
-- be recorded as having failed.
|
||||
--
|
||||
-- The counters are nullable-by-default zeroes because most tasks count nothing: a
|
||||
-- housekeeping prune has one number and it is already in `detail`. A run that counted
|
||||
-- nothing is drawn without figures rather than as four zeroes, which is why the API sends
|
||||
-- them only when `processed` is non-zero.
|
||||
ALTER TABLE scheduled_task_runs ADD COLUMN IF NOT EXISTS integration_id TEXT NOT NULL DEFAULT '';
|
||||
ALTER TABLE scheduled_task_runs ADD COLUMN IF NOT EXISTS processed INT NOT NULL DEFAULT 0;
|
||||
ALTER TABLE scheduled_task_runs ADD COLUMN IF NOT EXISTS changed INT NOT NULL DEFAULT 0;
|
||||
ALTER TABLE scheduled_task_runs ADD COLUMN IF NOT EXISTS skipped INT NOT NULL DEFAULT 0;
|
||||
ALTER TABLE scheduled_task_runs ADD COLUMN IF NOT EXISTS failed INT NOT NULL DEFAULT 0;
|
||||
|
||||
CREATE INDEX IF NOT EXISTS scheduled_task_runs_integration_idx
|
||||
ON scheduled_task_runs (integration_id, started_at DESC)
|
||||
WHERE integration_id <> '';
|
||||
|
||||
CREATE INDEX IF NOT EXISTS scheduled_task_runs_task_idx
|
||||
ON scheduled_task_runs (task_id, started_at DESC);
|
||||
CREATE INDEX IF NOT EXISTS scheduled_task_runs_time_idx
|
||||
|
||||
Reference in New Issue
Block a user